NEAR NEAR Core Overview, 8 Jan 2021

Previous Meeting

⏯

youtube image

►

From YouTube: NEAR Core | Episode 03: Runtime State

Description

An in-depth overview of how NEAR runtime operates with its state.

Follow the latest from NEAR Protocol on,

Website: https://nearprotocol.com/
Discord: https://near.ai/discord
Medium: https://near.ai/medium
Twitter: https://near.ai/twitter
GitHub: https://near.ai/github

#NEARCore #Blockchain #FutureIsNEAR

A

Right: hey everyone thanks for joining again, uh this is the runtime walkthrough, we're gonna be going over the internals of our runtime, specific transaction runtime and its design, and uh this time we're going to be focusing on the state and how runtime updates and manipulates with this state right. So let me start with this scheme here so uh near uses. Miracle patricia try uh for the to for the state in the run time.

A

Similarly, to how ethereum works, we actually at some point took ethereum code and we still even have one file called nibbleslice.rs, which was taken directly from parrot implementation or ethereum client. I think um so, I'm not going to be going into what miracle patricia try is because it's design is quite complex. Only thing that you need to care about is that it's a tree and um it's basically prefix based, which means, if you have a node, um a key that says that is a sub key of another key.

A

Then it's going to be apparent of that node in the tree. This is the property that we're going to be actually exploiting um that we're exploiting in our uh runtime design.

A

So, uh as I said, the state is stored in miracle.

A

We also have a persistent miracle, patricia try, meaning when we do modifications to to the tribe. When we write something into the state.

A

What we do is we just update only the the part of the of the tree that that is necessary, so, for instance, if we, if we made an update to the bottom, most note here this one, so what we're gonna do we're just gonna recompute the path all the way to the top like this and and link and link uh the new nodes that we have produced uh to the children of the previous versions of this notes and then we're gonna have another try another tree uh just with a different route.

A

So um basically, this is going to be one big data structure and the the root of the of the tree is going to be identifying which snapshot of the state are we currently working with?

A

So this is a an important thing that you're going to see in the code is that the state of the state is identified by the tree um I'll, try, data structure, and what is this? What is the root, because the root is basically a um like a pointer to the verse to the version of the stream all right so, as I said, we're using miracle patricia try.

A

We have persistent tree in our code base that we use to maintain the changes to the state and, as I said, the state is identified by the tree by this data structure, the one that I have highlighted with the blue bracket and the root all right. So now, let's jump to the code.

A

Base there you go.

A

And look again at this method called apply.

A

That is like a central method of the runtime, as we discussed last time.

A

So last time we went over the actions that run time is taken, how it processes the the transactions and the receipts. So this time we're going to look at what is the artifact of these operations like? How does it update the state, and you can see that it takes two things here that are related to the to the state, um the tri and the root.

A

So that's why I was explaining that we're using persistent, try because resistant tree, because the root is basically the identifier of the specific snapshot of this state, and then we also have another thing that looks like state, but it's basically a misnomer.

A

It's called apply state, but it should have been actually called context because it just has some information about what is the context of the execution of the of the runtime rather than really actual stuff related to the state.

A

So it should be renamed to context, and this structure should be also context.

A

So, at the beginning, when the runtime starts executing the the batch or the or the chunk, in this case the batch of transactions for the chunk, um you see that we are creating the try, update structure.

A

So we get this, try put it into the smart pointer, it doesn't matter, but then we create a triad based structure from the from the try and the root and and we have actually two of them and uh and then we pass around this state update structure, which is basically how we interface with the state so try update is the the structure that we use to um to communicate with the state, so it's the main from the runtime.

A

So all the operations that are about modifying the state are executed on this state update object here, and you see that that we are passing it around with um mutable reference, because that's where we're modifying things initial state is used only in one place. It's used all the way down in this check. Balance stand so check balance, as you remember last time. Is this uh mega big assert that verifies that we are not minting tokens out of nowhere and uh well we're not. We are not creating unexpected tokens and we're not deleting uh talk.

A

It's also at all consoles unexpectedly, and that's the only place where the initial state is needed, because it looks back on what was before uh what was what what are the balances of the accounts before and after so that's the only place where initial state is needed.

A

And the two main functions in the try update that you need to pay attention to are the finalize and the commit. Let me go here.

A

So the finalize and the commit a two main function, two main functions that basically explain most of the try update. So that's how you can start understand and try update by from the commit and finalize so as we execute transactions and the receipts and the chunk, we want to be able to roll back the state changes that are made by the transactions that fail similar to how it's done in ethereum. If transaction fails, it doesn't matter what it has modified in the state. We're gonna uh we're gonna roll roll it back anyway.

A

Finalize is called only once. It's called at the end of the chunk execution, so commit is called after each after each uh after each transaction, and it was also called at the end of the chunk where we gonna be modifying.

A

I think, let's see some extra information like up delete receipts right. Remember from the last time we discussed what delayed receipt is it's the receipt that um moves between the chart or from shard a back again to shard a, and we just didn't, have gas to execute it. So we put it back into the queue that is stored in the state and and we're going to execute next time. So that's pretty much the places where commit is used after each transaction and to say delayed receipts.

A

All right so, correspondingly with commit and finalize, there are two data structures here in the try update one is called committed. Another one is prospective changes, so you see we still keep the pointer to the try here, but it's um immutable like we are like. We are not actually mutating it uh when we, when we work with a state- and we say, update this key value, we're using try, update and what it actually does. It writes the change into the commuters.

A

So, let's see where this set is oh perspective. Sorry so, for instance, you see set is the method that we use like a low-level method uh that is able to modify the state and what it does. It doesn't go into the try itself.

A

It goes into this essentially hash map called perspective and just inserts this new key value. So it's basically like a diff. We maintain the the the simple div on top of the try, which is just a map and we insert changes in the when the changes are done to the try.

A

Interestingly, when we go to uh when we use when we read from the try, we have to read from all these uh structures that we just looked into so we we first try to to see whether uh we have it in perspective.

A

uh Then we see if we have it and committed, and otherwise I think we should be going to the try yes yeah, and otherwise we go to the try. So basically, there are like three levels and try update prospective committed and the try itself and when, for instance, we execute the contract because the transaction is getting executed and their contract reads some key value from the state or some key from the state behind the scenes. Runtime is first gonna. Try lookup, do we have it in perspective?

A

No, do we have it in committed and only then go and get it from the from the try? If it's not there, so the try would be the most expensive operation here, because these are just regular hash maps perspective. Well, I mean b3 maps, maybe I don't remember and committed, but the tri is a very complex structure. So it's not just the key value storage.

A

um You would need to iterate over the entire try just to make a read, and this is by the way, the design decision that we're going to to change, because we realize that we don't need to read iterate over the try every single time uh when the contract. Let's say you read some key uh from this from its state. We can keep the flat uh try flat, try and use it as a as a map here, but we haven't implemented this yet so.

B

A

Alex yeah we're writing questions in the chat. Sorry right, cool um right so.

A

As I said, finalize executed at the end of the block and commit is executed at the end of this each transaction, so one thing that you might notice here is that we are passing around a thing called state state change clause, and this is something that we're going to go back to, and this is also very important um to the state. But what it basically means is that every time we modify the state, we actually keep track of. Why we modified it.

A

So we have a special structure called state state change course that has enumeration of all possible reasons why we might define the state you know in when we, when we run the runtime- and this is done so that later we can build complex things on top of our runtime like rosetta, which is the coinbase rpc api.

A

All right. Let's look at the chat.

A

Try is shared between all the contracts in the shard right, so it's literally shared memory. Are there any restrictions on the read write access of the state? um Yes, so, as I said uh the beginning, the the property of the trial that we're exploiting here is that it's prefix based.

A

So if you have a key that is, that is a prefix of another key like if you have, let's say account: name is one key and then account name concatenated with with some other identifier is another key, then the second key is going to be always a sub note of the first note, and so what happens is that when, when you work with the state of the account, it's always a subtree of the node, that represents the account no, the account itself, because the account is stored under the key value, a hash of the account uh nameless or maybe not hash.

A

I don't remember whether we hashed it or not, and um the state of the of the contracts of the account of the account is stored under the keys, um the name of the account concatenated with some identifier. So it's always limited to the to the sub.

A

Try of this account and we in this way basically sandbox uh sandbox, all the state rule uh related to this account- and this is also very important, because if we were not not doing this, that we would we would create some extra vulnerabilities in our runtime, because when we discussed the fees, what we said is that every operation on the blockchain should cost something because it costs a lot errors to execute it and it written over. The try actually cause things because try can be deep. uh You do some string comparison there. Well, um you!

A

If you modify the try, you may be maybe computing more hashes if you're going deeper down the try, and so if, if two, if two accounts had overlapping state, then they would be able to affect each other's depth of the try, which means they would be able to affect each other's cost of operation, but because they are encapsulated on this and the individual subtracts. They cannot do it and that's actually a good segue into looking how we update the try when we, let's say, execute actions.

A

So, let's go to apply action method in here and one of them let's say action.

A

Access key add key: here we go.

A

So you see that we passed down this action.

A

The state update, as I said, this is the structure that we use to operate with a state in runtime and um we both use it to get the information from the state using get access, key utility and uh set information about the access key.

A

So, let's, let's look into the set access key. This actually is a completely different crate, great, it's not located under the run time, it's located in this core store and uh what you see the set access key. It uses this low level set another level set utility which just operates with it's basically low level.

A

Like you see that all specific implementations they they use, one, the you know they use the same set of get function here, but what they do behind the scenes is that when you give it a specific try, key like the tri key would be access key account, id plus public key. It converts this.

A

This thing into into the sequence of bytes uh here and the serializer on the strike key is, is really really important because it basically describes the structure of the of the state in the entire, in the entire tribe of the chart, for instance, for access key. What it says. Let's look at the two back for the access key. It says: access keys key in the state is.

A

Well, some you know identifier account id.

A

Then the separator and then the access key itself.

A

And I don't think this: this access key should have been there.

A

Well, anyway, that's weird.

B

A

Okay, that was unexpected for me that it was here well, but basically the idea here is that the the key of the access key is composed from the account and id and the public key of the access key, so that basically places access key under the into the substrate of the account, and the same should be happening with contract data, so contract data like key values that contract writes during x, execution, is also place.

A

You'll see it's also prefixed by the account id, which also means that it's been placed under the subtract of the of the account, and uh you can see like other interesting things here, for instance, delayed receipts.

A

They um they don't live under the account. So there are like there are two. um There are two key values: two types of key values that we use for the delete receipts. One of them is indices. Another one is the actual delayed receipt, so both of them are needed to to implement the queue of the deleted receipts, and you can see that they're not prefixed by the account id, which means they kind of live on their own in the chart like they.

A

Don't live under account in the accounts that try, which might or might not have been a good choice actually.

A

And then the contract code, you see it also lives under the account id. That's weird that it's prefixed like this and not the other way around um something I would have to double check. So that's that's a very, very valuable function here. As I said, it describes the structure of the state of the state. Try in our code all.

A

A

So as we execute different operations, while we're running the runtime, we update in this state using this um high level function, set access key.

A

Whatever else is in here, set account set code um set, postponed receipts set, receive data, etc.

A

Yeah and the other thing about storage, which is also kind of related to the state, but since we just in this area of the code, I wanted to touch what the storage is in the engineer and and it's specifically a difference from the ethereum. So in here the storage is basically requires tokens taken.

A

So if you want to write something in the contract state, you need to have certain amount of tokens on the account of this cont on this account because we have contracts deployed to the accounts and if you don't have enough tokens to fail, you're going to fail to to write more data into the state.

A

So we require staking of the tokens to write something well mistaken, it's not the same staking as during validation, but we basically require certain amount of tokens to be able to write anything into the state and what what we're also doing is that we are computing. The storage usage, so storage usage is stored inside the account structure itself, so the account structure it has amounts of tokens, some amount that was locked because of the staking. Some code actually identifies what contract was deployed and also storage usage.

A

Nothing else is stored in the into in the account um data structure and the account id itself is not stored here, because it's been used as a key. This is the value of this key value pair of the account when we, when we write it into the state and the storage usage, is really important because it it is needed for the to identify. How many tokens are in here are unmovable, uh because they've been used for the state.

A

So that's that's. Why you're going to see stories you usage throughout the code base and also another thing to notice about our code base is that we use mostly and wherever we can, the checked arithmetics and I'm going to go. I got to go back to it soon, but basically checked. Arithmetics allows us to take care of situations when we do the when we might encounter the overflow- and that includes the situations when someone maliciously might have tried to create an overflow in the runtime.

A

So this is something that I also gonna get back to.

A

Okay, any questions so far try shared between yeah got it. Isn't it strange that a third-party transaction may result in locking of funds on the account of the contract? um Yeah it it?

A

It is very similar mental model to what ethereum has where basically, the the contract developer is responsible for the uh for the code of the contract and if the right contract in such a way that some methods remove tokens uh from the from the contract balance, then it's on developers, responsibility and similarly, if they create a method that modifies the state of the contract and locks more tokens on it, then it's also part of the developer's responsibility that they created such method and maybe exposed it to the public.

A

So it's a very similar thinking in here.

A

All right, let's move on.

A

Oh well, maybe actually, let's look more into that into the try, since we start looking into the it's into its internals.

A

So here we have. This. Try update. As I said, it has the try, the committed and the perspective and, um as I said already finalize, uh moves stuff, I think from let's see where it moves it moves from committed. I think, to perspective: let's see what rollback is doing so rollback is basically undoing the transaction when it fails, and so it wipes the perspective yeah so perspective is, is the other set of changes that being created while the transaction is getting executed? If transaction fails perspective are wiped out?

A

If uh transaction succeeds, then they go into committed at the end, uh when we, when we call finalized what we actually do, is we uh we write those committed that those changes are that are uncommitted. We write them into the try, and this is a very heavy operation to do so. Try changes so here, try update, try, dot update is a very complex method.

A

If you start looking deep into it, it has this flattened nose, which is like a very complex thing, which is basically where most of the code about the modification of the state is it's located here in flattened nodes and insert delete functions, but we're not going to go in there because they're very, very specific to the design of the miracle patricia try.

A

um All right so roll back.

B

Another one as.

A

A side note: it would be really good to develop an approach to make user pay for his data added to the contract storage. This would make things simpler, e e.g. We would be able to keep fungible token standards, simple, yep, that's a good line.

B

A

We were having multiple brainstorm discussions about how we can change the design of our contracts like this. Maybe the standards do we need to have something on the runtime level or it should be implemented on the level of the nearest decay, but we haven't came up with anything that we have implemented yet.

A

All right, so, um let's go back to the apply, apply method in here and let's look into the try.

A

So the try is a very simple structure here. It has some counter which is needed for the fees and it has um a box of the trade. So we are using here this dynamic dispatch uh property of the rust uh that we can create box of something um that is a trade like.

A

We don't have a type specific type here yet, and there are three implementations of this trade in our code base: it's um try, memory, partial storage, try, recording storage and try caching storage, and these three things correspond to three different use cases of the runtime, which are all very important to understand and right now, because we are running only one chart, only one of them is is relevant right now, which is called try. Cash and storage.

A

Try, cash and storage is the only one that is relevant while we're running a single chart, but the other two already in the code base and they will become relevant uh once we enable challenges if we're going to enable challenges.

A

So let me explain to you what this tri cache and storage is, and recording storage and partial storage.

A

A

To this drawing so our runtime can operate in basically three different ways.

A

The first one, which is the most straightforward, is when it produces the block, so it receives a set of transactions, receives it needs to produce a new block.

A

This is the case of the try, try, cash and storage. In this scenario, we are just working with ordinary try. We are taking transactions, making some modifications and we're done with it. We produce we produce some chunk, we spit it out, distribute it through the network.

A

uh The second case is when runtime validates someone chunk, so someone has distributed a chunk, and now runtime has to rerun all the all the transactions on all the receipts that were used to produce the chunk and, at the end, it needs to verify that this state that arrived to the same state that is being linked into in in this chunk, because chunk links the the root of the state and when it does it, it uses try recording storage, which means that it basically is recording all the all the things that it's doing to the storage, and it is needed in case if the verification fails.

A

So if it verifies, if, if it, if it runs that run if it runs the transactions and it somehow at the end, notices that it arrived to a different state road, then something fishy is happening. The chunk producer produced an invalid chunk sign and distributed. We need to slash them. We need to to do something about it, but in order to act on it, you need to collect the proof.

A

That means you should have been recording. What were you doing like? What were you executing and that's why we have try recording storage, because, while we're verifying the chunk, we are recording every single operation that we are doing with the state and if the verification fails, all the changes to the state that were done are put into the challenge where we say we have a proof that someone misbehaved and this challenge is distributed over the network and then it's used to to slash and undo I mean and to ignore the chunk.

A

So that's why we have tried recording storage. The reason why we're not using ordinary storage is that it wouldn't be technically feasible to take the state of the entire chart package into the challenge and distribute it around. The challenge should be a small nifty proof that that is not a large like hundred gigabyte message. It should be something really small, and so uh that's why we are not distributing the entire state.

A

We are distributing only the part of the state that was touched as we were executing the transactions in the chunk and that's why we need to record everything that we're attaching so, for instance, in this image, if the contract- let's say this is the this: is the contract, um whatever some exchange, if it's been executed um and it modified some key values, then.

A

Then uh the the storage- let's say it modified this key value, this key value, then the recorded storage, would be only composed of the part of this of this on this try which corresponds to the modified keys and all of the all of the parents. So this is going to be the recorded store, the required storage or the recorded state.

A

Like suppose, we were executing the the chunk and we failed on the first transaction that was exchanged, then that would be it if we, let's say failed on the second transaction. Instead, that was running- let's say some erc20 here and it also modified some stuff. Then you additionally gonna also include these things.

A

So when you compose the challenge, you take the stuff that you have modified.

A

You package it into you package it into the challenge and you send it around, and then the third use case of the runtime comes into play is how does someone verify the challenge? How do other nodes verify that this challenge is actually the correct one? And it's some chance has indeed misbehaved and that's where the third type of the storage has been used.

A

Tri-Memory, partial storage, which is basically means that we are not right now, operating runtime on the whole state we are operating on whatever we were given, whatever sub subset of the state that we were given and uh executing executing the contracts. Only using this try and if we accidentally step out of this, try while executing executing the contracts. That means the challenge wasn't correctly constructed.

A

Like let's say we were executing the challenge, trying to verify that some chunk producer indeed produced invalid chunk and when we run an exchange, it went and went here that doesn't mean that the chunk producer was wrong. It means that whoever constructed the challenge did not do it right and so we're just going to throw away the challenge, because it's an invalid challenge.

A

uh But uh the difficulty here is that, because now you're operating on a partial state, it's just code wise, more complex to work with it right. So there are like three three different modes in which runtime can operate and there are very far reaching implications of having these three different modes that extend outside the state, and one of them is that you treat errors very differently.

A

So the errors that were that some errors that were can be considered to be.

A

Let's say the error of the runtime: the runtime failed, because it has some overflow can can lead to a note shutdown when the runtime is.

B

A

To produce chunk, but it can lead instead to uh but but but when you're doing verification of the chunk, it can lead you to discarding the chunk. Instead, um you understand this. This is a very, very important difference about the runtime, because if we accidentally mess up this these errors and how we handle them, um then yeah we're going to have vulnerability in the runtime code.

A

So again in in a standard scenario, you might be shutting down the entire node just because your runtime encountered an overflow. Let's say it was computing. The um the check balance right, let's say not an overflow, let's say check, balance thing is, is the one that's been.

A

B

A

Once here and inside the check balance, you have a lot of stuff in oops. I cannot call that um so you see here we have probably lots of safe, math, yeah, save, add, etc.

A

Let me see, save add balance and whatnot.

A

So if we're running the runtime and trying to produce a chunk and somehow we fail in the safe at balance, because we all have overflown uh it's just our fault- it's maybe there's a bug in the code or something um and we shouldn't overflow when we're just producing the the producing the chunk.

A

And if this happens, that means there's a bug in the code and then the the node should panic and just shut down and not do anything.

A

However, if we are verifying the chunk and someone's give well, if you verify, if you refine uh sorry not the chance, if we verify the challenge and someone gave us the state that intentionally has balances- let's say it has maximum balances on on accounts that we modify then we're going to overflow, but that would not should not lead to the node shutdown. It should lead to just the challenge being discarded or um or the chunk being considered to be invalid.

A

So there are very different treatments to the errors depending on which mode you execute the runtime in, and it's really really important to not mess it up and treat them correctly in each situation.

A

Do you have any questions see? There are like lots of questions, this probably very complex topic here. Have a side note. It would be really good to um that's what I read. Oh god, damn it. I bought a shirt.

A

If there is an overflow, it may be, because the node got an invalid state from the previous epoch chunks producer. Should we shut down node in this case it might be because the node got an invalid state from the e from the previous epoch chunks producer.

A

Shut down note in this case.

A

Well, I mean it shouldn't be able to build on top of the invalid state from the on the pre on the previous chunk. That has has been invalid.

A

As far as I understand.

B

I think it shouldn't build up this state, but it shouldn't shut down entirely either. Probably there is a if previous people's channel just intentionally submitted invalid state like, for example, having some accounts balance, which is almost maximum possible, and then there is a transaction that sends further tokens to that account so that the balance overflows as a result of processing processing that transaction.

B

So if a node encountered that that it has an overflow during processing of transactions, but I think it shouldn't shut down because of that state is invalid. There is a change coming, probably so. It should be able to validate this challenge and to roll back to a valid state and continue building on top of that valid state.

A

Yeah um well good thing that this code is not enabled right now in a minute because we're running one shard yet, but this this is very intricate and it's really easy to mess up. So I don't know exactly what we do in this case.

A

Maybe we do what you say. We do new guinea.

A

But yeah I mean when we're going to be enabling the challenges we would have to audit this code, many many times ourselves and by many people. Is it right that the states sent from other chunks should have tried root, hashes calculated after each receipt application? This is the only way to construct short challenges right.

A

um Well, maybe it would have led to shorter challenges. That's actually a pretty neat idea, but that would definitely impede our performance because the recompen, the update of the try, is maybe the bottleneck, or maybe the bottleneck or one of the bottlenecks of our tps.

A

And for many other blockchains, that's also the case there that recognize that recomputing, the hashes in the miracle patricia try is a major bottleneck and some things there might be hard to paralyze to if you have like very deep things happening.

A

um So we do not want to recompute the miracle, patricia, try and for the root. uh Every time a processor is sit which we we do it only at the end, when we call this finalize, remember, try update finalize method, that's when we actually recompute the try and we compute the route, but that leads uh to another interesting thing about the merkel about our state. Let me go back to sharing the ipad.

A

So you see, since we update in the state this the state try only at the end of the chunk chunk production or chunk orification, as alex said, we don't have state, tries or roots in between.

A

So we only know what was before all transactions and receipts that we executed and what was, after all, transactions and receipt that were executed and and and some some block some blockchains even actually go further. As far as I know, some blockchains don't even recompute the state route, every single block. They do it uh like every several blocks because they want to have higher tps.

A

For us it has. This implication that I start explaining is that we try to record every single reason why we well, we don't try. We have to record every single reason why we update the state.

A

So if we update the account, we don't just like write a key value, we provide a reason, a cause in our code base. That says currently we're updating account.

A

Let's see, where is the supply action.

A

Well, let's say: apply.

A

So because, somewhere here um yeah, so we have state change course.

A

So uh you see what kind of causes we have here we have like it was processing of the transaction. So that's a simple one. So that's when we convert transaction to receipt.

A

When we are processing the receipt.

A

uh When we postpone in the receipts, update, update and delete receipts and updating validator accounts and yeah, we also have a special cause here, which is we shouldn't be actually right into the disk, and this one is a special one. It's going to cause the runtime to throw an error and the place that we're using it is when we are, I think, running runtime in uh in a read-only mode. I think that's when we basically run runtime also into different modes.

A

One of them is when runtime actually modifies the state another one uh when we're using it. For the rpc reasons, when someone wants to do a view, call to the contract without submitting transactions using rpc, they actually gonna trigger the runtime um and.

A

And this will not cause any um changes to the state, but if the contract attempts to write something to the state and rpc will return an arrow and say well, you cannot do a view call to the contract method. That actually does some artifacts, like it tries to do a cross-contra call or tries to write something to the state.

A

uh That's I think, as far as I remember, this was used for yeah. So the reason why we have all this accounting of all the changes to the state is that later we map a very low level modifications to of of the of our runtime to the state of our runtime to other apis, like rosetta by the coinbase so rosetta by the coinbase. It's it's an interface that they use to communicate with various blockchains and they try to unify them behind this interface.

A

So they have some common notion of balance, some common notion of account and the way we map it to our entities, our accounts, our balances, is using this very, very low level. um Operations like someone has written something in something into the uh account and modified as balance.

A

For instance, that's a very complex topic, maybe that deserves another com, separate video on its own, maybe by blood flow, and not me um all right so important things to remember about the try update again just to go over it is that in try update, you have basically free sources of the of the information when um runtime is deciding. Is writing something in key key value, storage or reading, something from the key value storage, which is the try itself committed and prospective collections?

A

The two main methods of the of the try update are finalize and commit commit is called uh after each single, successful transaction one or receipt when transaction receives and successful. The rollback is called and finalize this called at the end of the chunk execution.

A

And what it does it actually recomputes the entire try, which makes it a very, very computational heavy.

A

Operation then.

A

A

Code here is really important one because it basically describes the structure of our state so by by reading this specific method here to back, which this tells you how we represent certain keys and bytes. You can reverse engineer in your mind. How do we store certain pieces of the accounts, data and other data in the state like? Where do we store delayed receipts?

A

How do we store the contract data under the account id.

A

A

All right, let me see whether I should cover anything else.

A

So uh one last thing I think that is also very important to mention- is that we do not have a try iterator in our try accept one specific case, so our try, we operate with it pretty much as the key value storage that we cannot iterate over, which was done on purpose, because we thought that at some point we might come up with some design of the state or of the try that will be much more high performant, but at the cost of not being able to iterate.

A

So by dropping the requirement that the the key value storage does not need to be iteratable, you might be able to construct a much more efficient, simpler and performant implementation of keyboard storage, and so when the contracts communicate with the state as they execute, they are not able to iterate over the key values.

A

If a contract has some map inside that it implements for, say, let's say to store erc20 account balances, then it won't be able to iterate over them, because there is no operation called iteration available to the contract. So the contract would have to emulate the separation.

A

It would have, for instance, to enumerate them with integer numbers and store the length of this factor somewhere to be able to iterate over them, and that was done intentionally and uh one one of one of the big reasons why it was done intentionally. Is that uh like when I was talking about the challenges right, and I was saying that, if you want to, if you want to challenge some um chunk that was produced in an invalid way,.

A

You need to construct. You need to record all the changes that you were doing while you were executing these contracts in this chunk, and there becomes. There turns out to be an algorithmic difficulty here, where the contract not only accesses key value storage like in this way. You know just like one at a time, but it tries to iterate over them.

A

Then your what we call weakness is going to be really hard to construct and it's just like it possible. It is possible. We actually have it, maybe even in our code base, but it makes things much more complex that we don't want the contracts to be able to construct this kind of situation.

A

However, we do iterate over the state. Try in only two situations. I think so one of them is when we want to iterate over the access keys of this account. So, for instance, you want to retrieve all access keys. So this account and, as I said when you saw in the code base the access keys, they're all prefixed by the account id, so you might be able to just iterate prefix prefix wise in the try and get access to all the access keys.

A

But this is not something the contract can do. So we don't need to worry about the complex, complex situations that the contract can create and the other situation is when you we're deleting the account and when we're deleting the account, we need to delete all the data associated with this account, which is everything under this try and which means we need to iterate over this. Try and physically remove every single element from it. I mean we might be like.

A

Logically, we might be able to to drop the entire try, uh but we are still doing right now, iteration over it. Every single, every single element in this try and uh the problem with that is that the code that does the iteration over the try is is very, very complex and error-prone.

A

A

Sorry at least yeah try, update, iterator, try, update iterator is very, not trivial. You see.

A

And what tri-update iterator does in addition to that, is that it needs to be combined with the iterator over this perspective and committed collections.

A

uh So there you basically have you, as you had written over the state, for instance, to delete an account you're, actually iterating over three collections. At the same time, you're iterating over perspective committed key values, and then you trade on with the try itself and then the code inside the try. Iterator is also very complex and one problem right that we have with try it rater right now that actually we should try to get rid of.

A

um Let me show it to you: okay, yeah! Is that the try iterator is supposed to be able to iterate. Well, I mean, let's, let's say you're saying you're trading from here to here: your iterator is range based, iterator, you say iterate from a to b. Right, so iterator would need to traverse like this.

A

The the problem with that is the cost of this iterator of every single operation in terms of cpu instruction and correspondingly, the gas is higher than if you are doing individual lookups of every single element starting from the root, and this speaks of an efficiency of our try, iterator implementation, which we need to fix. So it's it's. It's cheaper to look up every single element from the root than to iterate them in the try next to each other, because the try iterator code is is inefficient.

A

All right. I think that was a quite complex topic. Let me see whether anyone has any questions. Does anyone have any questions not in the chat.

B

Like when we're going to improve all those inefficiencies,.

A

Good question: whenever we're going to get someone who has time to do this, because this is going to have a very, very direct impact on rtps, so when people are asking us well, what is your tps of on a single chart, we're saying we have some numbers but they're kind of irrelevant, because we put very little effort and performance optimization of the of the tri, which is our major bottleneck when we fix all that the tps is gonna, be like I I don't know what's gonna be, it can be like something pretty good like many many times more than what we have right now max.

A

Couldn't this be a great candidate for a bounty nah? This is this is too too complex? I think for a bounty unless someone who is very very familiar, uh let's say with ethereum try.

A

So if anyone knows people like that who have time and willing to take bounties, we can we can discuss that.

B

A

B

Room, it's also inefficient and in fact the ethereum has below dps and expensive storage operation. I think because the storage implementation is not efficient.

A

Yeah yeah I mean there's like there is an insane amount of performance, optimization that we can do to our code, where each of them is going to be like at least double digit percentage improvements, if not several x, improvements um like uh we're, flattening the try right, not iterating the try, every single time the contracts accesses some key value in its state.

A

It's gonna be a very big difference and uh misha kever actually has a pull request. It's like one year old, where he started doing it, but he hasn't merged it, and it also was before we uh before, like we had this more recent design discussions about the sharding and um actually having state stored, not in the key value database, because we still store our state right now in the same rocks db. Columns as the other objects like blocks and headers.

A

Storing it in something like memory, mapped file or something very optimized would also create a very high performance. Improvement is the try that the state sent from the other chunks should have try route hashes.

B

A

Okay, I'll answer this question already all right, um no more questions um all right thanks. Everyone hope that was useful. See you next time we're gonna have another couple of videos about the runtime.

A