NEAR NEAR Core Overview, 8 Jan 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: NEAR Core | Episode 02: Runtime Action and Data Receipts

Description

An in-depth code review of how NEAR Runtime implements cross contract calls.

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

Hey everyone thanks for joining this, uh the runtime walkthrough session. Again, the topic today is going to be initialization from the genesis, actions and the receipts, and also we're going to look at how we actually execute those callbacks and the how the promises work uh in the runtime, because we've been talking last time. That nier provides a very friendly developer experience for the contract developers and that allows them to work with promises without thinking how it's been executed behind the scenes.

A

So we're gonna actually look inside this box and and see how promises translate into very specific messages. That runtime is passing between the shards and executing.

A

So we're going to start again with some analysis.

A

Of the cases that.

B

A

Do you guys see my whiteboard here.

C

A

Cool all right cool.

A

So again we have oops multiple shards in the runtime.

A

I'm gonna draw them like this bunch of shards. Each chart has its own uh in the blockchain. It charges its own runtime and let's say you have alice.

A

uh Who is trying to call contract bob just as a walk through what we discussed last time so see alice contract is trying to go bob contract and alice leaves on chart a.

A

A and bob leaves on shard b, so what's going to happen, is that the transaction is going to arrive. Oops it's going to arrive to this chart, so you're gonna have a transaction arriving to chart a and then this transaction is immediately getting converted into the receipt.

A

It's actually going to be local receipt. As far as I remember the last time we discussed that, when transaction and the and and the contract that it's calls or like the account that is, targets is on the same chart that it just becomes local receipts and it executed immediately has been converted to the receipt it calls contact, alice and then alice is actually going to send create another receipt that is going to be targeting contract bob and on the next step. So let's say this is block x and this is block x, plus one.

A

So, on the next step, shard b is gonna process this receipt and execute it.

A

A

Yes, so now, let's take in a more complex scenario, the more complex scenario is uh when you have a callback. So let's say alice wants to execute contract bob but at the same time have a callback back to alice.

A

This can be useful, for instance, when you build an exchange so in, for instance, if I, if you're working with exchange engineer, you would call an exchange and say exchange token x, we're talking why exchange contract will send a call to the contract x, send a call to contract y in parallel and then, when I receive the callbacks, both from contracts x and y and uh and try to do something like you know, swap them for instance.

A

So the callbacks is like a very important part of the of the or the contract building experience in here. So let's say again that we have alice contract bob and then once contract bob executes alice wants to be called back again so oops.

A

A

Then it's getting called back again to alice um in in in ears decay. The way you would write it is that you would create a promise to bob, and then you would attach a callback that says call me back again when bob is done and and the way it's going to work is when in terms of the receipts is again, the transaction arrives to shard a uh then the local receipt is being processed, then chart a spits out.

A

The receipt that travels to shard, b and and block x, plus one is getting executed, but now on the next block, shard b needs to call back alice. So obviously there needs to be like next step.

A

Oops next step like this, and uh this is gonna, be let's say, block x, plus two and in this block x, plus two um shard b, is actually talking now to chart a let's spin off the screen by.

C

The way max, it's a bit off screen.

A

The stuff, on the right hand, side: okay, can you can you see the the shards, so the diagram or not or is it cut, for we can.

C

See uh the cut off side of the far right two squares charts: okay, god, damn.

A

It, let's try doing something about it.

A

Okay, how about now it's better.

A

Feel better cool, so uh shard b now needs to call shard a on the next step right, because the callback is happening and the way it's going to work is there's also going to be a receipt flying because you need some information need some exchange of information between sharp bna, but this receipt is going to be called data. Reset data is because it just tells the result that b was executed.

A

It just has some information that well b has executed, maybe with certain even data, because you want to have callback, maybe with some data and that's why it's called data reset and the receipt that does that calls uh that calls contract b the first time it's called action.

A

Reset all right, so this is pretty much uh the high-level overview of like very, very simple approach. Oh a very, very simple scenario where you have a callback, cross-control call with a callback, and you have both action receipt and data receipt by the way the local receipt is also going to be action receipt.

A

Now, let's look at the code in those actually action and data receipts to see how what they are.

A

One second, let me see, are there any questions? I think there might be questions all right, discuss later um yeah. So right now you see my.

D

Id again, it slower uh smaller cool.

A

There we go thanks all right, so um this is action received. Let's go back to the runtime, so the way I always start you're working with the runtime, as I recommend you last time you you start with the apply method, which is like a go to for most of the information you see the receipt here, which is the central structure that I was discussing.

A

Receipt has some predecessor id, which is just an information who emitted this receipt in case of the transaction. That is going to be the account that signed to the transaction that was converted to the receipt.

A

um If this is a receipt that was created by another contract or in case like when alex contract called bob contract, the receipt that's lying to bob is going to have his predecessor alice.

A

Even if alice was not the one that was actually signing. The original transaction receiver is the one who is receiving this receipt, and this is some unique identifier that we're going to use to identify this receipt globally in in the blockchain and the this is where most of the stuff is so there's data. Now so you can see it can be either action or data.

A

So that's what I was talking about. An action receipt contains those actions that that we visited last time. So it actually tells you what to do. It can tell it tells you create account, deploy contract, function, call, etc. The data the data received doesn't have actions. It only has a blob of data.

A

Maybe so, uh if you, if your callback does not require transferring some execution result, for instance, alice called contract bob, but when bob was executed, when the contract bob was executed, the function the contract function did not return anything it returned like void, then this is going to be null um and uh and otherwise it's gonna contain some serialized execution results depending what kind of language you're gonna use. It's gonna have different data in there and I'm gonna probably use different serialization methods.

A

So that's the difference between action, receipt and data receipt. The data receipt only contains the execution result of of the contract. When it's been used for the callback, an action receipt actually has the actions. As I said um so here. Here is uh an interesting thing. We now start looking into the uh data ids, so uh the receipt has dependencies.

A

So it has dependencies called input, data ids, and it produces something called data receivers, which also has some data. It is so what does it mean?

A

Let me go back to this drawing so in this drawing when the way, the way we execute this callback right do is by creating a receipt that waits for the data receipt to arrive. So when, when here, when we convert transaction to the receipt and execute the receipt, so the moment the receipt is executed, we realize that we need to call contract bob, but the same time we're going to wait on contract bob to to finish execution.

A

So what we're going to create we're going to create an action receipt here, but we're not gonna execute it immediately. We're just gonna we're just gonna store it in our state and then when and then we're gonna identify that execute this receipt only when you receive a callback from bob.

A

So it's like a dependency.

A

And then what happens is that when bob finishes execution and it emits data receipt, this data receipt here and this data receipt arrives to shard a the runtime finds this action receipt that we stored for for later and the first step. It identifies this data id.

A

Of this data receipt is equal to the data id mentioned in the callback, and it now knows that it can execute this stored action receipt and that's how callbacks work in runtime.

A

D

In this case, max again, we we're not seeing parts of the the red the right part of that stuff, but during the time when you're moving this stuff, uh my question would be the the purpose of creating of action. Receipts is this for, for the sake of saving a network here, network.

A

D

Why why why bob contract is not able to to send an action receipt back to uh there? There are targeting uh the same contract offenders.

A

And so there are probably several potential designs of the runtime to it that could achieve similar result. So one of them is that bob could maybe send an action receipt back to alice.

A

um Then that means that bob needs to know that it needs to send an action receipt, so bob contract, when it executes, needs to know that it needs to tell like a very specific execution to alice, and it's kind of seems to be like a very simple thing to implement. When you have a single course counter call when alex calls bob. But if you have, let's say you know like alice, calls bob and then bob calls carol and then carol calls whatever I remember, danny and then etc. And then someone calls alice back again.

A

Then, as you call in this chain of contracts at each step, you need to remember somehow for your receipts that at the very very end you gotta call alice. So you're gonna be passing this data.

A

You know around with a specific action receipt for alice, with specific execution results like all through the chain, and in this case, what you are doing is that you are just passing the the data id uh which is uh kind of simpler, um because it's just like an identifier rather than the whole structure, that you're like tossing around the blockchain, and that's like the big, uh the number one difference. So the number two difference is that we also allow um the following scenario.

A

So alice can call bob, then alice can in parallel call carol, so alice would construct promise for bob, it would construct promise for carol, and then it would say when both of them execute at the same time, when both and carol executed the same time called back alice and in the example with the with exchange. That would be quite obvious as an example. Right, you have an exchange.

A

You want to have a contract, call to one token that locks it certain amount. You want to have contract another token that locks certain amount. You want to wait for both of them. You don't want to be called uh twice. You want to could be called once when both of them are ready, and so you need to kind of bundle them together on the runtime level, say only like bother me when all this stuff is done, and only then I'm going to be executing something.

A

So when you want to have something like that, where you, where your callback is, bundled it's easy, when you have uh multiple data ids rather than you know, you pass information, because because then, if, if you say, if you say for instance, that alice needs to be called when bob and carol is done, then neither bob no carol is going to be the primary responsible contract for colin alice. So who is who is actually going to be like emitting this action receipt? Bobo carol? I mean they're kind of equal in this position, yeah.

A

That should be neither of them, and this is actually a great question because a segue to multiple data, it is so in this case alice has two dependencies, so alice uh action, receipt.

D

Yeah max and by the way it is a hell in the screen happening at least what I see yeah, I don't know. Maybe you need to to restart the screen sharing.

A

Or maybe just uh find a zoom out button a little bit. Oh.

D

It's like it is leaving lots of artifacts actually really from the from the improvement.

C

D

A

That's unfortunate, oh from the movement of the stuff, but is it uh do you have to see any artifacts now.

D

Yeah, yes still seeing it.

A

What, if I do, this is better better, much better wow, zoom, okay, apparently sharing a screen creates artifacts, but sharing this window does not.

A

um I like hector zoom great, uh so alice has um alice, is an action receipt, so you you're gonna, have this action receipt here right this one that waits for some data id. In this case, let me raise it.

A

Oops, in this case, alice is going to be waiting for two action receipts. So in this case there are not two actions. Two data ids, two data ids, so alice's action receipt is gonna, have two dependencies and uh incoming dependencies. So it's actually gonna be waiting for these two data ids to arrive.

A

While these other two uh action receipts that we meet and one for the bob and one for the carol, they don't, they don't have any data edits that they depend on, but they themselves emit data. It is each one each of them emits one, the data id and when ls executes the first time it emits two data. uh No I mean yeah, it doesn't emit any data when it executes the first time.

A

So uh going back to the code.

A

Went back to the code, that's why you see input data. It is here as a vector because action receipt can be waiting for multiple data ids to actually arrive to this chart.

A

And you also have a multiple data receivers as a vector, because um it's a single, a single promise, can be weighted on by multiple other contracts.

A

So that's why I have a vector here.

A

um So this is a high level overview of how cross contracts calls or calls work in runtime together with callbacks.

A

Let's see, do you guys have have any questions about it? I.

C

Haven't I have like a like kind of more general question, um and maybe I missed this from the first session but like how, where are receipts stored? Is there like a separate like mempool, mempool-like thing.

A

Yes, so these receipts that I would just talked about the um um whatever we're going to call them, specialists that are waiting they're stored in in a queue that is implemented on top of the state uh state. Try that we have so our state try, um it stores accounts right. So it's a heretical structure.

A

It has a consonant with some contract data under each account, but it has a very special separate key at the very top which is um specific uh to the uh to the to the receipts that are waiting on on to execute this specif some accounts and they're waiting for certain data. It is, and they might be, actually stored under each of the accounts.

A

um That's not not in the root of the try. So this is something I don't remember exactly by heart.

A

It would make sense, then, to be stored under the accounts, because that would allow dynamic sharding to actually work, because I mean, if you, if you're a shard, you cut through the accounts, and you want your receipts that are waiting for certain data ids to travel together with the accounts that they're going to be actually calling the contracts on okay.

A

um So, let's go again into the actions just to let's go for this actions that we can actually perform on the on the with the receipts, make sure that we know their content, so one of them is the create account account action. As I said it doesn't have any information inside, uh because the way you create an account in here is that your receiver or your transaction or the receiver of your receipt is actually the account that you want to create.

A

If you, if you, if you, if you are creating a transaction that creates an account. So when you go all the way back.

A

Into the receipt here, then, the receiver id is the account that is going to be created if the first action is create.

A

Account and uh a similar logic applies, for instance, through the transfer, so transfer only has deposit like it doesn't say whom you transfer it from and whom you transfer it to, because if they're all deducible from the predecessor uh or like signer and through the receiver, the receiver is the one who is receiving the balance.

A

uh The predecessor is the one who who sent it and very similar to the function. Call function, call doesn't seem, doesn't say who you call it.

C

A

It's deducible from the receiver, uh it only says: what's the method name, the arguments, how much guess you used to do this function call and the attach balance?

A

So when you attach certain amount of balance to the function call, it works exactly like transfer. It's just like a bundled action. um These are. This amount of tokens is going to be deposited uh before the function executes.

A

And when function, if function fails, it's going to be undone, so we also have stake action. We're not going to touch this. Yet this is a complete different topic. Add key again, it doesn't say whom you're adding this key for, because it's reducible.

A

C

Can we see the access key struct that was in there.

A

So the interesting thing about account design in in here for those who don't know, is that we have multiple access keys for each account and this access key, some of them they can be like suda. They can have full permission. They can do anything with this contract or this account they can delete it.

A

They can call any method on it, so that's full access or it can be restricted to call in only specific methods on the contract that is deployed to this account and that's what is called a function function, access key that specifies the the method names listed method, names that you can call um and even whom you can call.

A

For instance, I can add access key to alice that says that uh this access key can only call certain method on contract bob and allowance like how much gas the whoever uses access key can use from that account to do the calls.

A

And the the interesting thing here is that we have nones not per account but per access key.

A

The idea is that multiple users can use the same account but different access keys, and if there was common nouns for all of them, they would be interfering with each other like they would be crushing transactions of each other all the time, because they would have conflicted nonsense because they have separate nonsense for separate access keys.

A

um There is no problem with that. So then, the nouns the nonsense are stored. Per access keys are not not per account, and this is also like a very important thing.

A

And then everything else is quite simple: there is delete key delete account, it's pretty straightforward, um except one nuance here that when you delete an account in here, you have to specify beneficiary because, like whatever tokens you have left on this account, they need to go somewhere and we want to incentivize users, obviously not to like lose it.

A

So, especially because we have states taken in here. States taken means that when you, when you want to write something in the state near you, you're going to have certain amount of tokens locked on your balance, it's a different model than the one ethereum uses. So in ethereum, when you write something into the state, you burn certain fixed amount of gas and then, when you delete it from the state, you get reimbursed certain percentage of this gas in here.

A

What you do when you write it in a state, you lock certain amount of tokens on your balance like they become not liquid, you won't be able to transfer them out and then, while you're using this state, the tokens that are locked, they're kind of paying for the state maintenance for the inflation mechanism.

A

Just because you you have this tokens locked and you cannot stake them, you are using. You are missing the opportunity to stake them and therefore you are not getting a return on the investment from your tokens and that's how you pay for, for using our state certain amount of time by not being able to use the tokens and uh therefore, when account is getting deleted, whether you have contract on it or it's just a a raw account.

A

Without anything, you gotta have certain amount of tokens unlocked, even if it's small account it's gonna, be small tiny amount of tokens unlocked when you delete just an account with some access keys, and we want to incentivize people to just not toss this tokens away and actually move it to a different account, so delete actions delete transactions in near blockchain. They have beneficiary that specify who is going to be receiving the stuff okay. So I'm going to read for the questions.

A

What, if receipt with attached tokens is reverted and by the time it arrives back to the originated account the account the account is already deleted. In this case, the tokens are going to be burned lost. There is literally nothing we can do in this scenario. um Maybe bowen can correct me if I'm wrong, I think they're burned.

E

Yes, yes, they're uh burnt are also burnt if, if you delete account and beneficiary id does not exist uh in that case, the tokens are supported.

A

Yeah the tricky part about beneficiary is, you might not be able to verify upon the deletion of the account that this beneficiary exists, because this beneficiary might exist in a different chart, and the whole point of the near blockchain is that our state is chartered not just computation. So shard a doesn't know what the state is on shard b and whether there is there it does exist or doesn't exist, uh bob's account in there.

A

So you can lose tokens by just providing a type like a typo in a beneficiary.

C

Just real quick while we're on the topic, this is good timing. Had a solidity developer asked me this morning what our xero address is for burning. um Do you want? Is there information on that or like how we don't have a zero address.

E

Yeah there is, there is now right now there has been talks around providing an api for host function for burning tokens, but as of now as of now, there is no certain way you can, you can make sure your tokens are burnt. You might think that you can send tokens and to a non-existing account and then delete your own account to burn the token it mostly would work. The only problem is that someone can squad that account while you delete your account.

E

So in the end you, instead of burning the token you just sent to someone else, so there is no reliable way to to so that you can be 100 sure that you can burn the tokens.

A

Well, you probably kind of can say that sending it to all xeros account another, not all zeros, oh god dammit. We actually can anyone can actually squat anything. You know in our blockchain conversion here, yeah, okay.

A

um So the second question is from michael.

B

I think we can have implicit account with an invalid key.

A

um Yes, yes, that could be great um and please account there's a couple of the different topic also that we're going to cover in the future very interesting one michael bursch asks: does the beneficiary get state other than near tokens as well, agnft or wrapped rc20 other than new york tokens as well.

E

So you're talking about the case where an account gets deleted and it needs to stand.

C

E

Yeah, the state is not transferred, only the tokens are transferred. Only the token knows: okay.

A

Transferring the state is is a bit too too much yeah.

E

It's it's hard for sure, because it's not clear, what's valuable state what's not, etc.

A

And also it's very large, you really don't want to think about what happens when one of the messages in your one, one of the receipts just carries around you know, like hundreds of megabytes of data um mike asks, I can create bernie or move all keys, then you can burn by sending to goodbye bernier or any other sub account to the brics account. That's pretty neat! It's a good idea.

E

I mean yeah, that's that that that I mean that kind of burns a token, but not not actually burns them like they. They still exist like it's a there's, a slight difference between uh uh tokens that are not accessible and tokens are like actually burnt, because in the total supply it reflects different values, and this also affect the inflation uh in the end, uh so there is still yeah I mean you can like kind of lock or burn like like in a nominal sense that yeah, but.

A

If you, if you were able to delete berm near after sending it, then it would have been burning, but I don't think you can do it with our current constraints. On what kind of sequences of actions you can execute. So, as I said last time, the sequences of actions uh in here there you cannot have anything like you cannot have arbitrary actions, because we we try to take a very conservative approach with it.

A

We say we allow almost anything but things that we have concerns with, for instance, when you create delete account multiple times we just prohibit for now, and we figure it out in the future. If actually, there is a use case, so, for instance, a mic scenario will not work, will it now it will? Actually you can actually do it. You can create a transaction that creates burn. I mean removes whatever doesn't need to remove all the keys, creates sense, sensor, tokens to goodbye, bernier and then deletes bernier in the same transaction.

A

It might actually gonna burn tokens.

A

uh All right, so, let's move on from the action receipts. I hope I got you properly confused here, but I think we actually reviewed almost every field in the receipts, which is great except the gas price. So this is going to be the topic of the refunds. That's where it's going to be useful, what the gas price is and um yeah. So the other important thing here is that you can see that very frequently.

A

We specify who's the receiver of something, for instance, with the data receiver, we're not just saying data id and that's it we're saying data id and there's the receiver id, and that's because of the sharding that to to know where you need to route. This information you need to know which chart it lives on and to know which chart is on.

A

You need to know what what what is the receiver id, because the sharding in our blockchain happens according to the accounts, so we like, you, can think of it on a high level, as we literally just like mod accounts, like account um identifiers.

A

So you can really really easily deduce from the account id uh on which charge it lives on, and so you would know where to route this data id. So this is something common for the code of the runtime. Is that very frequently in the data structures? You will see receiver id for some reason next to something, and that's because we need to know where to route this information.

A

All right, so we have 25 minutes and I think that's enough time to look into the another important method of the runtime, which is supply, genesis states, so the difference between apply genesis, state and apply is that well, as the name suggests that you call it only when when you, when you execute genesis, block which is just once and the apply is being called on, every new block and the difference here is that our genesis contains what we call state records and state records.

A

It's basically our way to describe what the state, what we want. The look, the state to look like when the blockchain starts- um and uh we want to have certain number of accounts, for instance, already exist upon the genesis right. We want your foundation account to exist in there. We want accounts of our investors to also exist in the end of our employees. Well I'll! Please read it later. Maybe even uh some of our investors traded later, I'm not sure, but near foundations should certainly exist in there.

E

Yeah, actually, only a few accounts exist in the mainnet genesis, cool.

A

Yeah thanks for correcting both, then we also want to have maybe these accounts to have actually some data in them and some contract deployed on them. So we want to have some contract code to be deployed already and upon genesis start and the data to exist also upon the in this in this contract and also access keys to exist, and now there is the interesting uh the interesting part comes in, which is postponed, receipts receive data and delayed receipts.

A

So, uh let's start with the latest.

A

uh Well I mean let's, let's start first with the motivation: why do we need anything but the, but the top things uh so before we launch the main net, uh our blockchain, the testnet, specifically one was undergoing forks frequently because we were experimenting with the code and we were- um and we were just like it was easy to do a fork upgrade rather than you know, to do a proper upgrade and credibility was not implemented. I think back then um either, and so we wanted to take whatever the state.

A

The blockchain was at the given moment of time and start with this state, as that was um a genesis.

A

So it's a proper fork, but additionally, what we wanted to uh to uh to carry over are also with the receipts because, as as I said last time, we want to have a guarantee that receipts are always going to be executed, so in your blockchain receipts are never lost, because if you allow receipts to be lost or not executed, then you cannot have any contracts with any kind of guarantees built uh on across the sharks on near blockchain, for instance, as I gave an example with exchange that calls one token contract and calls another token contract, so suppose that we have a following scenario: when your exchange first calls one token contract to lock tokens with a callback then calls another contract to lock tokens with a callback and then, if they both successfully lock, you perform that the swap.

A

If they don't, then you unlock them. If you, if you lose the receipts, then you might lose the receipt that does the unlocking, and so your tokens might end up locked even maybe permanently. So. This is like a very simple scenario when you absolutely need a guarantee of the receipts to be executed, and there is a lot of work and the complexity inside the runtime code to ensure that this actually happens and the delete receipts here is one of the reasons why this is exists.

A

So when you want, when we were doing fork on the test net, we wanted. We didn't want to lose the receipts that were delayed that were like in the process of being executed, but were not executed yet, and therefore we would we would scoop these receipts from the delayed queueing from the state and put them in the state record same. These are the late receipts. You can't execute them at some point. You cannot lose them.

A

With the postponed receipts, there is a slight difference here that deletes.

D

Can I ask a question about the delayed receipts? What's the point in keeping the delayed receipts, if you're restarting the blockchain from the very beginning, you will not have respective contracts there deployed and stuff like that.

A

But you will, I mean when we're starting, we were taking the state when we, when we were doing the fork of the of the blockchain.

D

Yeah: okay, we're.

A

Basing this state, uh so there might be actually the you might be, creating a fork right at the moment when someone was doing, let's say an exchange uh swap and you don't want them to end up with log tokens or anything like.

D

A

Got it and uh and the difference between postponed and deleted cities that the late receipt was the one who was actually lived in the delayed queueing of the of the blockchain? Maybe because, maybe because there was a congestion at that moment, so remember the last time I said the delayed receipts are actually received. Written in the state carried over between the blocks postponed receipts is actually the receipt that was just simply in flight, so it was a receipt that was emitted by the block right.

A

You remember that when we process the block and near not only we output the state as the new state as the artifact, but we also put what is the next set of the receipts that we need to route between the shards so postponed receipt is the receipt that was created, but it didn't wasn't the part of the delay receipt, but you still need to execute it. So that's the difference between postponed receipts and delayed reset and the received data is also the thing that we just touched so the received data.

A

It could be a situation. For instance, let's go back to our drawing.

A

A

Like, let's go back to this scenario,.

C

A

Alice and bob oops and second here so it could be that, um like bob, has already executed and sent the date id uh the data to to back to alice and right. At this moment we decided to to fork the testnet, but but carol did not execute yet so some of the data has arrived and some of the data hasn't.

A

So we we cannot execute alice yet, but we already, but we need to keep the information around, that the data has arrived. Part of the data has arrived for ls to be executed, and therefore we have this received. Data thing that exists um that exists in a as part of our state records is that maybe we had some complex cross-contract calls with callbacks and part of it was executed and part of it was not. You know. Some of the data has arrived. Some of the data hasn't.

D

Is it true that local receipts can become delayed resets.

A

uh Yes, the local receipts can become delayed receipts. uh Let's actually go back to the code.

E

uh Look, I think it it can if it's so congested, that local research cannot even all be executed in the same block.

A

Yeah or, for example,.

D

Yeah yeah no continue.

A

So you see like when your local receipts are executed. You check on every step. Am I above the gas limit and if you are then, instead of processing, you say right, I'm delaying the certificate and just like, since I've been talking a lot about the delete receipts, let's even take a peek into this function and you can see what literal does it just takes this receipt as this and it writes it into the state. So you can see this some set function, state update thing: what really does it just writes it into the state?

A

Try it someplace! That's that's all! It does and also updates the pointer on this. The later seed queue by one. So it doesn't do anything besides that um right, let's go back to the.

D

Apply genesis state an additional question max, so so so it is, um it is independent of user. Whether the receipts that that are created within the tree of calls are are are coming to the delay state or not. Does this mean that making a receipt a delayed one is costing zero gas.

D

C

Execution, gas.

D

Costs are can be calculated beforehand, yeah.

A

So the the putting receipt into the delayed queue incurs extra cost um that we don't have as a separate fee form.

A

uh We consider it as a part of basically the burden that validators need to carry the problem with the fees is that you need to make um to draw a line at some point like you cannot create a fee for everything in a blockchain like you cannot. You cannot create a fee for sending things over the network like what is your network? It's such a such a volatile thing. You cannot like assign a very specific fee to it. uh You cannot assign fee to.

A

A

Rpc things right talking to the rpc another thing and and therefore therefore, you need to you- need to draw a line sometimes and say most of the fees, especially like things that are deterministic most of them. We try to have a fee for them, and and also we try not to have fees for things that are unexpected to the contract developers.

A

So again, we don't want contract developers to be like, oh my god, why does my thing certainly cost more than it than I thought it would cost? Why do I need to? Why do I need to care as a developer, that there is something inside the black box of the runtime happening and my receipt is being put somewhere somehow and because of that, I pay extra cost and that's basically one of our criteria.

A

So when we decide whether whether to make it a fee or not, is that is it gonna surprise the hell out of the developer and if yes, then, maybe it shouldn't be a separate fee.

D

Yeah, so that's the reason why I'm asking this. So if, if we are attached a fee from making the the receipts at a delayed one, then this is something unexpected to the developers.

A

Yeah, the the good thing is that the execution of the receipt is like probably order some like three orders of magnitude or something like that more expensive than putting it into the states. Just like.

D

B

A

Around yeah, so the execution of the receipt right. Now it's on the order of terra gas, like whatever single digit targas. I think um the writing something in a blob of data into the state is uh way below single digit targets. It's like zero point and then you have like either two or one zeros before you actually like 0.02, or something like that. It's quite cheap, so negligible all right!

A

So uh let let's look uh in here. So here you see, this is the this is the apply? Genesis state function right, so we iterate over the state records that are stored right in the genesis. uh This is the part of the genesis. That means that, as you know, we use genesis to identify the chain too.

A

So if we have two blockchains that have everything equal but different state records, those are two different chains: the they're part of two different networks, so the state record is as important as having you know anything any other config likes the block size, for instance in in our blockchain. It's identified. It's it's a unique identifier of the of the chain.

A

There is some stuff about the storage computation which we also gonna skip for now. This is a completely different topic. um There is this stuff is convoluted and you, I don't think you need to. You- need just a high level idea of what what the hell is postponed receipt is somewhere here, it's actually going to execute them or set them to execute to be executed later. I think the reason for this this code is about updating validators.

A

As I said last time, it's also a separate topic discussing how validators are updated, what what happens with the stake, etc- and everything else is all about. Updating the um the state and discussing runtime state is also a separate topic, so we covered the apply genesis state now.

A

um Let's now look at the apply method again so in the apply method. As I said, this is like the most important method of the runtime and I think the second most important method of the runtime that you can start looking into is process receipt, since most of the logic is about the receipts right, transact logic, value transactions, quite simple, because transactions getting converted to the receipt almost immediately, that makes basically puts most of the complexity of the runtime inside the receipt execution.

A

So processor is seat. It follows this very standard. Rust pattern of you know having a really large match against the tag the now and what you can see here. If you actually look into the data id uh the receipt data is that you're gonna see that the logic here is all about waiting for all data to arrive when when there is a callback, so like a lot of the code here, maybe more than half of it is all about it's about the case.

A

When you have a callback and you're waiting for some data to arrive, and only when it arrives only then you do some execution, so we're not gonna deconstruct this code. Here you can go over it yourself. I I hope you understood the high level idea of what date id is and how the callbacks work and uh yeah. So you see there is some something here called like. Pending data count, we actually count how many data we still yet to receive, and once it becomes zero, then we actually execute the receipt.

A

um So I don't think we should go into any more topics today, because other topics are quite large and we shouldn't start on them. uh Do you guys have any more questions?

A

This is this is this might be the most complex topic of the runtime by the way and the most uh like new in terms of the mental model, all these callbacks and the receipts, and all this data, the data flying between the shards. Everything else is going to be more linear and straightforward.

A

So do you have any questions on this topic.

B

Well, maybe not exactly on this topic, so there is a problem with this system, of which I thought for quite some time. So we, as you said we have, we have a guarantee that the receipt never gets lost and I think this is most important for action receipts.

B

But this is on the lower level, but for the contract there is a problem which can make a receipt appear to get lost specifically if the execution runs out of gas, then for the contract, because such execution is reverted from the point of the contract, this receipt is lost and the problem is that you can't really guarantee that you have enough gas for anything.

B

So there is always a risk that your execution will run out of gas and in ethereum it's much simpler because, like the entire transaction gets reverted, so it is as if this transaction didn't exist, but for near it is possible that multiple execution need to happen either. All of them need to happen, or none of them needs to happen, and it is possible that one of them is completed and the second one runs out of gas.

A

Yeah yeah, so that's a fundamental problem on the shower blockchain, where you have asynchronous contracts, um which is if your contracts are like you're, incomplete clean that can do anything.

A

You can try your best to estimate what is the? What is the amount of gas that you need to attach to it, to always guarantee that it's gonna be enough to execute it, but you might be wrong and any kind of callback, which is can also be a turing complete program can actually run out of gas.

A

So we either need to. If you want to to allow users to make like a like a foolproof mechanism uh for unlocking and for the callbacks, we either need to drop this completeness through incompleteness, and we see whatever you execute as a callback is actually can be limited in gas and we can guarantee it and it's always going to work and not never going to run out of gas or we need a complete different mechanism, which is a lot of synchronous, calls, which is also what we've been discussing in some research meetings.

B

So I thought I think what I thought about was more like the first approach, so I thought I had an idea to have some sort of event queues. So the idea is that the callback had some item to an event queue that is part of a account state, and so this action of adding this like promise, result to an event. Queue is not during complete, so it is possible to guarantee in advance that it will not run out of gas, and then it is maybe possible to invoke a regular callback as well.

B

But if that callbacks callback runs out of gas, it may be possible to send a transaction to reinvoke the same callback with the information from that queue like with more guests. So you, if that call. On the one hand, it is possible to have a callback which can do something like schedule further receipts, for instance like more do something else, but on the other hand, even if that callback runs out of gas it, it is not lost completely like. There is still a record state that this contract can use to redo this action.

B

If someone sends another transaction to get to give it more gas to run.

A

Yeah, that's one of the mechanisms. I also like uh the approach that libra has where they just special case, anything that is an asset and they create the entire virtual machine around the fact that you cannot accidentally burn some asset. So it's like a it's like a first class citizen for them all these years, 20 tokens and we were actually brainstorming ideas around that there are multiple at least one proposal in apps.

A

We call it safe where we ex like extend our runtime with some extra host functions that will allow you to have basically the libra functionality, uh specifically for the for the asset uh for the asset manipulations, so that that could also be a solution. But I also like the qeq is more universal, um but it's it's harder, it's harder for the developers, because now they have to think in terms of the skew like they need this new abstraction to deal with.

A

uh I mean we don't need to turn to the restoration.

B

It is possible to hide the thing behind some sdk functions and instead just make it like possible to redo call back if it was. If, if the previous attempt to run a callback failed, then it may be possible, like for anyone to send the transaction, to pay for the gas to try to run the same. Exactly this. The same call work again, so this is like people approach. It shouldn't affect the security, so we always had the guarantee that the callback can be invoked at any time like possibly much later, and so now.

B

The difference is that if execution of a callback failed that anyone can attempt to re-execute it exactly in exactly the same way, but with more possibly more gas, but also almost once so one once it finishes, it removes like itself from the queue. So it cannot be the same and call that cannot be called again.

A

Yeah something like that, and we can even create some uh design patterns for the contracts that people can just like use as a recipe book without really thinking too much about how to design something custom on top of the skewer using sdk cool. uh So let's wrap it up. That was, as I said, probably the most complicated complex topic in the in the runtime in the in the right time code and I'm happy that we are through because that will allow us to understand.

A

Other things is because, as we're going to be reading the the rest of the code, like around the state around the fees around the wasm execution, we're going to see a lot of these receipts and data ids and all things like that, and we will be able to understand what it actually means. So it isn't was important that we covered this topic early on, but I hope it didn't discourage you from attending more runtime book through videos, because they're going to be simpler than this one.

A

All right thanks. Everyone thanks.

C

So much max that's great thanks. Thanks bye.

A

A