From Sharded Blockchain to Sharded Smart Contract From Bowen Wang NEAR

[Music] hello hello hey everyone uh I'm bone from near and today I'm going to talk about a very exciting uh topic shed smart contract oh before uh diving into what that thing actually is um let's first uh reveal what the uh what sharting is uh hopefully by this point everyone knows uh knows about charting uh but just in case you don't uh let's quickly uh kind of talk about what what it is uh so basically it's a a technique to scale blockchains uh in a nonshared blockchain um you know like Bitcoin or ethereum mainnet um and many others uh what people do is that there are a whole bunch of nodes could be a thousand of them uh but they all do the same thing uh they all process the same transactions uh do the same state transition and agree on the same result that if you think about it that's kind of inefficient um because every node uh by having more nodes in the network it's not actually improving the performance of the network uh so sharting is idea that well let's uh do something else which is that uh we have the network uh being divided into different shards uh so each Shard you can think of it uh kind of like its own blockchain uh inside each chart every note um who validat data Shard does uh process the same transaction validate the same state transition and um agree on the same state route uh but between different shards they're doing completely different things they're they have different state they process different transactions um and so on uh essentially the entire network uh is being paralyzed by the number of shorts and uh kind of the more shs you have uh the higher serut than network has as a whole uh so let's uh uh take a closer look at uh how how it kind of actually works uh I'll briefly describe some things about uh what n has build for sharding uh so in the traditional sharding design uh usually each Shard has its own blockchain called Shard chain and uh there is some uh um some Beacon chain or main chain whatever you call it uh that orchestrates uh different things between shards for example uh assigning validators to shards uh making sure that the cross shard transaction is valid uh and all of that there's a problem which is that uh if each shart has their own blockchain is actually very complex uh because on each Shard you can have your own Fork uh what happens if uh uh when you send a transaction from Shard a to Shard B it actually goes from a a fork on Shard a to a fork on Shard B and what happens if one of those Forks gets rolled back later uh that becomes very nasty so in near n design we actually simplified things uh we basically just say that uh uh there's only one chain uh this chain um uh each prod on this chain contains chunks uh which are Shard blocks uh from every Shard uh so there's no actual Shard chain uh even though logically uh you can kind of build this sh chain from this uh main chain um and uh this uh simplification uh makes a lot of things easier and also not only easier to implement but easier to uh reason about the security and so on um yeah so uh brief high level overview so features that it has only one chain um and uh each sh doesn't need to have uh maintain its own Shard chain uh the execution is asynchronous because um in order for cross star transactions to work um how it works is that it first gets executed on the um transa on The Shard where the transaction originates and then a receipts uh get spaed and sent to the the destination sh to execute um and uh the security relies on serus validation uh that's a new thing we launched uh last year um so what so the what the problems that charting trying to solve I think it's mainly twofold uh one is this uh scalability problem that I talked about earlier which is that well you kind of want the St of the network to be High um and um here in a short shorted blockchain design uh the super put should roughly scale linearly with number of shards so kind of more shards you have more seut you have um that's a great way to improve the performance of the network uh but I think uh one thing that uh uh it's not being talked um much about is that it's actually a very effective solution uh to the state growth problem uh because in a nonshared blockchain you not only have the throughput problem you also have the problem that the state is growing uh potentially very fast um in the cases of chains like salana and you need a way to address this problem otherwise at some point the state of the blockchain would be so big that it's infeasible for uh the nose of in uh of the blockchain to hold the state uh and uh and that becomes a um a problem for the sustainability of the blockchain that's why people talk a lot about how you address a state growth problem um but for short thing you can think of it as as a natural solution to that because it essentially just divide the state into the state of the charts um so that uh when you have when we have more shards each Shard uh doesn't need to have that much state so it also addresses that problem but um there is uh often overlooked detail that actually make it um more complex which is that uh while Shing um does address both of the problem uh there's a interesting Corner case um and a very important one as well which is that a smart contract itself can grow very very large um so if you think about the popular defi um contracts the likes of Unis swap uh or on near there are uh those consumer based apps uh like kijing or hot that have like millions or tens of millions of users um and when the state of uh all of those uh users are stored in the same contract it just gets very large um and not only that um the serut of the um smart contract is actually limited by the serut of The Shard uh meaning that um even though you can have many shards um this smart contract this very large smart contract will have to live on a specific Shard and because it lives on a specific Shard the serut is naturally limited by the serut of A Single Shard so it doesn't really um benefit uh from the the overall Shing design okay so how do we address a problem uh the solution is what we call shorted smart contract uh what does it mean it means that um the smart contract essentially simultaneously exist on all sharts uh the contract code is global uh it's available on every chart uh and uh instead of uh storing the uh user uh account uh user data on the smart contract account uh it actually Stores um on under the user account on each Shard so in this way it scales uh linearly with number of Shard and actually Leverage The Power of sharding so let's take a look at some concrete example uh so let's say you have uh usdt contract is uh simple fundable token smart contract and you have Alice uh and Bob U who both uh have account registered on the usdt smart contract uh so today what you do is if you want to send a usdt between them is Alex cost uh ft transfer and uh having Bob's recipient um and there's like you know sending one usdt um but this entire call happens on usdt near the execution all happens with seeing the the same smart contract uh now what what if we make it shed uh so now it's it's actually more interesting because uh it's no longer happening the execution no longer happening on the usdt Don near uh account what's actually happening is that uh on Alice account there is a usdd near Nam space uh it's kind of like this uh sub account in a sense of the Ariston near accounts uh and it Stores um all the relevant data that alice. has on usdt uh and similarly the same codes for Bob and if Alice wants to send Bob some usdt what actually happens is that um this Alice near usdd near this entire like complex namespace calls the name space on Bob's account uh and says how how much token you want to transfer um and when get executed on Alis account uh the number is deducted and then when the receipts get executed on bobs account uh it's incremented there uh as you can see in this whole process the usdt near account is actually not touched um so this is almost the same as if you transfer you do Native token transfer uh between Alis account and Bob's account um because they can live on different shards um and it doesn't have to be Al Bob and it could be like millions of users doing the same thing uh so it fully uh take advantage of uh what charting allows uh allows you to do okay that sounds cool but how does it actually work um so there are two main technical components of the sharded smart contract design uh one is what we call uh Global Contract code uh and two is this ability to store data uh on the user accounts uh rather than the smart contract account uh so what does Global Contract code actually mean it means that um it's basically a special transaction uh that instead of deploying uh this contract code on some specific account let's say alist here it actually deploys into this um kind of global um State um that uh that is simultaneously available on our sharts uh so roughly how this works is that uh when you do this deploy contract uh transaction uh it generates receipt that goes to Every Single Shard uh and on Every Single Shard um the validators maintain this uh State for the Global Contract code uh and the state rules being updated when uh it sees a new contract code being propagated to the shart so it validates that all the so every single shart uh validates the state transition of of the Global Contract uh State and um uh update the state route there uh the important thing to note here is that uh this uh special thing only stores Global Contract code uh it's not a general purpose uh storage because uh that that's very complex and also opens up uh uh whole kind of warm so we basically limit this to uh Only Store contract code and another thing about it is that this operation is very expensive because you need to have it simultaneously available on sh on all shards and essentially you burn a whole bunch of token to do that uh meaning that um it you cannot just Spam this to to attack the the network and making sure that uh people only do this when uh there is actually need for um so for example if uh let's say um alir wants to deploy a global contract for multi um and um Bob bobir um see that okay now there is a multis contract deployed and uh he can he might also want to have multis on his account uh because that's convenient um so what he can do is that um instead of deploying uh another multi contract which is expensive he can just say like okay I want to refer to this um contract deployed by Ariston either by uh the account name uh Ariston or by the contract hash uh and essentially this is a pointer uh to some U piece of the State uh so this operation is very cheap uh and as you can see this uh Global Contract code is already a very useful feature uh by itself um but uh in the context of uh shter smart contract is actually a prerequisite uh because shter smart contract necessarily has to have uh the code available on all shs okay now let's talk about the uh the second piece how do you make sure that um you can we can actually store user account uh um sorry store data on user account rather than on contract account um so generally the the idea is that um if you have a pretty expensive contract whether u meaning that you have a lot of users or uh you have a lot of transactions hitting the um the contract uh it's really because you store some uh some information per user uh if you don't do that if you just store some kind of static information or some uh uh something that's not uh kind of stored per user then generally there's no need for a contract to be shorted uh but let's say uh you know you do and um it's either like you know uh large def applications or some consumer application that Stores um maybe a lot of information per user so generally the the the abstraction is that you have this mapping of user account ID to some kind of data the data is obviously um contract specific uh and um you know what you do today is said the data is actually stored under the smart contract account um rather than uh on the user account um okay so let's look at this uh example so let's say you have a uh the usdt smart contract on the left hand side it's a single smart contract it's basically like this giant table that Stores um mapping of account ID to balance right so for example Alice has one usdt Bob has 10 usdt Kyro has 50 usdt now what it means to store on the um user account is that uh it's kind of like the inverse of that uh the usdt uh smart contract the usdt account itself doesn't store uh much information uh and um uh all the all the balance information is stored under this namespace that I talked about before so for example on Alis near uh there is this namespace al/ usdt near um and inside that namespace storage uh it's it has uh some kind some kind of keys say it's balance and it actually stores the balance under the key and uh same for Bob and Carol um and as can as you can see um now we essentially change the uh the the storage Paradigm from having everything stored on the contract account to now actually everything stored under user account uh and as as we know uh sharding already deals with the uh kind of handling of the State uh of the user account meaning that it is actually shed based on some bound um so like you have all the user accounting this uh in the State uh Nam space uh in the state um State Tre and then you basically Shard based on some kind of boundary that's determined by some uh specific account uh so you already get that uh now what essentially what you get is that uh you also have this um uh contract storage sharted um uh just uh based on how charting Works um and you automatically guess that and um uh and if you have this contract that's very large let's say USD near has 100 million users um you still have the that account usdt near was very small amount of storage um and then the actual the the meat of the storage is now on individual user account uh so essentially you transform the problem of like one account having a lot of storage to lots of different accounts each having their own uh small piece of uh storage for this contract uh and this um this would scale uh which number short so this is a um very interesting uh change and obviously there's a lot of complexity uh behind scenes on how how it actually works how it handle the uh the r time and so on uh that we won't dive into uh today uh but it suris us to say that U uh this is a a solution that actually address uh one of the uh one of the big bottlenecks of the Shing design that people have today which is that you know what if you have a very large smart contract it actually allows to char a smart contract um and um have both uh scalable serut for the smart contract and also manage the state size effectively uh and it and with this design makes sharding a very complete solution to the blockchain scaling problem uh both in terms of the seput U but also in terms of the State uh size growth problem uh and we're building this solution uh at near today uh the first part of the um uh the components already down so we already have U uh Global uh contract code uh that is going to be released very soon and uh now we're uh working on the second part which is uh to allow uh smart contracts to store uh data on user account uh so that's it uh thanks