NEAR Lunch and Learn, 6 Dec 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: NEAR Lunch and Learn Ep. 05: Accounts and Runtime

Description

Here, Evgeny Kuzyakov discusses basic account models at NEAR. Including transactions, receipts, and simple transfer transactions. This video is great for beginners.

~~~ABOUT Lunch and Learns~~~
This is a new series of videos exploring a concept on the NEAR protocol blockchain discussed in the NEAR office at lunch. Grab a sandwich and settle in!
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

A

Hi I'm Eugene and today we gonna record a large serious about rantin and first question is what is run time so run. Time is a thing that runs everything on a blockchain, so let's say we have transactions coming in and then we process transactions and we get a result. So this is handled by run time, ignoring all the blockchain stuff. So what is the input and output is handled by the run time? So, let's start first with the account model run time.

A

We have accounts so in the state in a traditional blockchain like if your emo Bitcoin accounts are represented by a public key, and this public key is an account ID. So.

B

What's the public key, the.

A

Public key is just a unique cryptographic.

A

Primitive that is known to everybody who want to interact with your account, and it's part of the pair of public and private case of private key is what you have publicly is known to. Everybody want to interact us so on mere accounts. I actually not keep by the public key, but they have a just unique user name. So, for example, my account ID can be you Jim, and this is what we call account ID within the account.

A

We have a different type of fields, so account usually has a balance and balance is indicates the number of tokens the account holds and tokens are measured in a 10 year and at the near is 10.

A

Eighteen of a single near we do this to keep the balance as an integer. So it's not a floating point, and at the near, is the smallest Union that we have for the token, then, on account, they also have log balance and log balance is used for staking or indicating how much you wanted to stake. A currently staked near is a proof of stake system and stake is the log balance that is used by the validators.

A

So if validators act properly, they earn more stake or more rewards, and if they act maliciously, they gonna lose their stake. So stake guarantees for validator start properly, also an account on ever account. We may have a contract. This is a code, a contract, a smart contract that can act on on your behalf, on behalf of the account so.

B

You said on every account: we have a contract, but we might have a contract. What do you mean by that, like it might yeah.

A

We might have it or might not have it so by default, account doesn't have a contract, so it's empty, but it also can't have a single piece of code that we call it account contract, so contract can have a state, and this state is a storage of the contract. So let's call it storage.

A

And finally, to be able to access the account, we can have multiple access keys so on again on aetherium or on a Bitcoin network. Your public key and corresponding private key gives you access to the account so by using a private key. You sign transaction that guarantees that you are donor, the account and you can act on behalf of this account near we have multiple access keys and they can have different permissions.

A

So, right now on access keys, there's two type of permissions first is full permission, access key. It acts similarly to theorem. It gives full access to your accounts, so you can do all type of transactions and second, is.

A

Function call and function calls is a specific access, key that only grants permission for calling some other contract it guards, which account it can call and also how much tokens it can use to pay for the fees and which method it can call. So it can be very restrictive and we'll come back to this slightly later, once you talk about transactions, so why we talk about accounts, as you might know, near is sharded system, so we have multiple charts that both contain state and processing.

A

So a single chart contains only some accounts of entire system and let's say we have four charts and I'll draw them as blocks here. So this is for sharts and on every chart we may have multiple accounts.

A

So my account Eugene I'm gonna belong to one of the shirts.

A

B

Wouldn't it be split up between all the shards like, isn't that how decentralization works.

A

No, so every account belongs to exactly one shard, but how this is decided is not part of the account logic, so account doesn't control which chart it needs to be like, and this is controlled by the blockchain, which can rebalance accounts from shark to chart and actually make charts equal weight. So if some account is very heavy in terms of having a lot of storage, so access key, this chart might have less other accounts comparing to some other shirt. Okay,.

B

A

On near run time, the way they actually process it, we always assume all accounts belong to the different shirts. So, even if we have two accounts, Eugene and Ashley that belongs to the same shark around time, we'll make an assumption they both belong, like they belong to the different shirts. That is done. That colocation of accounts to the same chart doesn't give you any benefits and that's why we don't want to developers or users to be thinking about collocating their accounts to get any benefit. This is done for two reasons.

A

First, if you want to rebalance it, they we don't break the any logic of the developer that used collocation and second, it tells easier to design and think about this, where you don't make an assumption that something is local, but what is always available for what we guarantee that, if you interacting with the account all this data that I mentioned, which is balance, log balance, contract storage and all access keys, are all located on the same chart, and this is going to be important when we talked about transactions.

A

So this account, do you have questions about accounts.

B

No, let's move on to conductance cool.

A

So let's talk about the life of the transaction standard simplest intersection on the Bitcoin chain is when one account transfers tokens from to another account on year. We call this transaction transfer.

B

For clarity sake is this similar, like a bank transfer like yeah.

A

It's just like exactly so, let's say: let's say: Alice wants to transfer tokens to Bob and it's gonna be 100 a 10 year. There's a small amount, but it's good for the example.

A

So for this to happen, Alice needs to create a transaction. So transaction is.

A

Contains the following fields, which are important: first: let's erase account fields.

A

Transaction contains signer.

A

Signer I did this is the account ID that sends the transaction in this case is Alice. Then it has a receiver.

A

Id- and this is the account ID that will receive a transaction in this case. This is Bob and then transaction contains a list of actions. So this is another thing that is unique to near, because.

A

You will talk about action slightly later in this case. Transaction that Alice needs to do contains only a single action, and this is a transfer. So this transfer.

A

Contains a field indicating how much talking or how many tokens Alice wants. The transfers in this case is going to be a hundred, and this is a transaction so now to indicate to the chain that this transaction is actually done by Alice and not someone else. Alice has to sign this transaction with one of the access keys, which contains a private key. So Alice has to sign this transaction by computing, a hash of this transaction. This gives you a unique field that she signs this private key and creates a signature.

A

Transaction also contains some additional information that needed to make transaction unique indicate which public key was used to sign and stuff like this. So.

B

How does that tie into run time right.

A

So around time actually receives a list of the transactions for every moment and it processed this list of transactions.

A

So transaction starts when Alice creates this transaction and then attaches the signature, and we call it signed transaction so signed transaction can now be sent towards the blockchain that will verify the blockchain layer I'm, going to verify that this transaction is valid and put it into the chunk, which is piece of the chart. The next block of the chart we call it chunks once signed transaction, arise to the chunk. This information is actually passed to the runtime and Trenton will process it and makes the necessary logic and.

B

How fast is that it.

A

Depends on the blockchain layer, so the V target to produce one block per second, and so this particular transfer will actually take about two seconds and we will get into this why it takes like longer than one second. So this is a signed transaction. We have it now and let's say we want to process it. So let's say Alice account belongs to this chart, while Bob account belongs to the next chart, so they don't different chart. So how is.

A

We can actually make it happen that tokens are transferred from one shot to another run time, because the Charlotte system also works on shirts. So on every chart there are going to be a different instance of a run time that will process charts independently.

A

This signature can only be validated by this given chart where account Alice exists. If a transaction lengths on this shirt, it cannot verify that L is actually signed, the transaction with proper key, because this shirt doesn't have information. The chart of Bob doesn't have information about the account of Alice, so it cannot verify the validity of the transaction.

A

That's why? In a Charlotte system we introduce a different type of transaction called receipt and receipt is a processed transaction that was created by the runtime itself, and receipt can actually be transferred cross charts through the blockchain layer and processed by the runtime on the other chart. So here's just I.

B

Want to break this down on like really simple terms, so I understand it. Basically, you have your your runtime and your px, which is your okay. So that's your transfer, and so it's the equivalent of like putting your credit card in a machine. You sign it in person and then something mumbled umbels up and up in the internet and then that's where the receipt comes from and then it comes out and lets you know kind of similar. It.

A

Kind of yeah: let's do the knowledge there, so you go to the store and you have your credit card with a chip on it. So when you want to make a transfer and pay for the item.

A

Visa sends your request. Let's say your credit card. Local is through the chip signs. This request. This is a signature that you created that goes back to visa. It then can transfer from your account to a store account and.

B

Then the story gets yours and.

A

Story gives the store gets the money and then their transaction is actually from here confirmed so internally. They don't need to know that this has succeeded to transfer to store so long as the signature is verified by your account. So.

B

Is that how it works for sure we.

A

Do have it somewhat similar, so the life of this transaction is the following. We start with the shard of Alice. It received a signed transaction.

A

It creates a receipt.

A

That goes to char the Bob.

B

To prove that it was valid and.

A

This receipt contains the amount that Alice transferred it contains hundred and ten year, tokens that when the receipt is applied here, Bob gets a plus hundred talk, it's cool and that's how it works. But, let's say just to step back that Alison correctly entered Bob's account name and she put something like Bob's is zero, so when it arrives to the shard, where this account supposed to be since shard of Alice actually doesn't know that this account doesn't exist. It redirects this to the new shirt where it's supposed to be, and this account doesn't exist.

A

Receipt would fail and generate a refund and refund is a receipt by itself, so it will generate a refund that will fly back to Alice and return this hundred tokens so.

B

There's a fail-safe in place: yes,.

B

How does runtime tie into that cool.

A

So now we can't step back to the runtime and what it actually has every moment. So every moment it has oh, every blog that it produced it has a list of signed.

A

Transactions and also a list of the incoming receipts and this receipts are collected from all all other shirts towards the current chart. So in a previous block, which had another chunks.

A

A

They redirected something to Alice, so all these three she is going to be there and all the new transaction that I also targeted going to be there. So what is a runtime? Does it takes this input and produces the output which is results?

A

So this is what happened when we executed some receipts and maybe local transactions. If, for example, Alice does something on her own account and also outgoing receipts?

A

This is a new receipt that was generated by this process, so in this case, transfer is going to be Alice.

A

It's a signed transaction. It will take tokens out of Ellie's accounts. It's gonna modify the alex ikonn alice account by removing the 100 dockets, generating new outgoing receipt that contains this hundred tokens that will go to the chart of Bob.

A

Bob will receive this receipt and apply it and process it and generate the result and increase the balance of Bob account by hundred tokens. So this cow, it works on a high level and next time we'll talk about function, calls and contracts. Thank you.