NEAR NEAR Blockchain Concepts, 13 Jul 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: NEAR Blockchain Concepts (3/6) -- Blocks, Transactions, Receipts, Execution Outcomes & Access Keys

Description

In this episode of NEAR Blockchain Concepts, we go over the concepts that are involved in the operation of NEAR Protocol network.

We will cover blocks and chunks production, transactions, receipts, and execution outcomes relation, and, finally, we will briefly touch permissions system (access keys) in NEAR Protocol.

Speaker: Vlad Frolov, Engineering Manager of Public Interfaces Team at NEAR

Useful links
- NEAR Block Explorer - https://explorer.near.org/
- JSON RPC APIs documentation - https://docs.near.org/docs/api/rpc
- Learn more about Transactions and Receipts - https://docs.near.org/docs/concepts/transaction
- Learn more about various types of keys in NEAR Protocol - https://docs.near.org/docs/validator/keys
- Reference-level documentation on Transactions in Runtime - https://nomicon.io/RuntimeSpec/Transactions.html
- Reference-level documentation on Transactions in Chain - https://nomicon.io/ChainSpec/Transactions.html
- Reference-level documentation on Receipts - https://nomicon.io/RuntimeSpec/Receipts.html
- Reference-level documentation on Actions - https://nomicon.io/RuntimeSpec/Actions.html

Follow the latest from NEAR Protocol on:
Website: https://near.org/
Discord: https://near.chat/
Blog: https://near.org/blog/
Twitter: https://twitter.com/NEARProtocol
GitHub: https://github.com/near https://github.com/nearprotocol
#Blockchain #FutureIsNEAR #NEAR #nearprotocol

A

um So last time we we ended with the description of epochs, I'm trying to remember where exactly I was uh heading to, uh but let's, uh let's probably just recap, a little bit um on the on the epoch side. So basically I I I don't think uh I had.

A

I definitely didn't open our docks, which I should have uh so we have docs, which is great. We have api over here, uh and here we have a lot of useful information started, starting with useful links where, like are available, we even have public archival rpcs, because these uh rpc endpoints only store five epochs.

A

They don't store the whole history for like for a reason of saving storage.

A

Rpc instances currently consume 100 gigabytes on main, I guess, and for full archival node. We already reach one terabyte, which is like 10 times more than on rpc, which makes sense to split apart. We can run more mainnet rpc instances to serve recent data and just a few instances with the whole archival information. So.

B

A

You only care about like latest state. You can like safely use this. If you want to look up historical data, you use archival very simple.

A

uh If you are not very familiar with like different tooling, you can use postman or carl all the examples mostly feature this http.

A

Utility and you can look up all the like information in the nice dock on the right side, there is a nice overview, so you can easily navigate through this very long page, uh and the thing that we are currently interested in is we'll be looking into network status. So there is a node status. You can use our pc to query. It's the the single node uh where, like what's its state uh in example, response you can see it reports the version of the binary rhyme there, the protocol version and various.

A

Information over there useful section is sync info which which tells at which block the current node.

A

Is right now, and so you can see latest block and whether the node is in syncing mode. If it's, if it's in syncing mode, it means that you'd better, not use this uh node to fetch latest data because it doesn't have latest data, yet it is still catching up with the network.

A

um There is also another endpoint which is uh well network info is not very interesting right now there is validator validation status. So well, when you query the leader's endpoint.

A

With a block heat or block hash, representing the specific point in time, you can face the the information at that point or you can specify null this. uh This is a legacy, the style of queries. As you can see, it's not very intuitive. What exactly that number or this strain is or whether you need to put null or empty array. I will refactor that later, but overall now indicates like latest and then you receive uh information about the current leaders uh we'll cover later validators a little bit later.

A

uh The useful part here is that uh this point also returns. You epoch start heat, so you know where the e, when e-book starts uh so, let's uh check it out.

B

A

B

A

A

B

A

So here we are, this is.

A

3 36 uh million.

A

690 is the block where this current epoch started. Currently, it's 36 million seven three three um blocks, so we are like in the middle of it. uh What's uh like what is the reference here is that uh we discussed last time uh in genesis.

A

Oh, it's in severe genesis over.

A

A

In genesis, we.

A

Have sick? Oh that's, weird one, uh weird naming sorry about that so epoch length over here is what we look last time it's on: it's! If block production is exactly one. Second, it is 12 hours. uh It represents 12 hours uh for one.

A

uh We went through this whole conflict uh talking about. Where is um like records that the genesis essentially defines, which uh accounts will be in the very beginning of the network and.

A

Yeah now I guess we are ready to dive into block specifically so.

A

Do we want to start with blocks? uh One sack I need to think about it. um Yeah, let's start with blocks so blockchain is name implies, starts with, like includes blocks which are chained together, and each block is produced by some um node, which we call validating node block, so they are producing nodes.

A

uh There are other types of nodes which do not produce blocks. They only follow the network, uh that's exactly what we have here in the reference we use rpc nodes. Those are nodes that are not validating there, just following the whatever is in the network, applying the same rules, but they do not take part in creating new blocks or accepting transactions and doing something about those transactions. They can receive transaction and route, the transaction to the nearest evaluator they in in their uh network internal peer-to-peer network.

A

So all the nodes near core nodes are part of the same peer-to-peer network uh with different roles. There are validating nodes. There are non-validated nodes that basically there are only two types of nodes uh on this level and then non-validated nodes could be there for different reasons. One of them they would be serving rpc traffic.

A

Another reason would be: they are serving backup needs so they're just following. They do not serve any traffic, they need to be there just to store the data and there are nodes like indexer nodes, which embed the whole near core node into into its own application as a sub process. uh It runs near core in different thread, while doing some other work in in some other threads.

A

That's a core essence of indexer uh framework and indexer implementation for explore using that framework and and boot nodes yeah, it's a special like roll that we assign, uh which, which those nodes need to be there to initiate that peer-to-peer process. So when, when we connect a new uh node to network, uh we need somehow to to let it like the entry point and we use some nodes that are certain this boot node role. You can use any node on the network to connect to, but uh to limit certain traffic.

A

We decided to go with a separate server running those nodes and we specifically assigned it to serve this boot node role, um yeah. I hope that that's not enough on the high level uh getting back to the blocks, so each validating node sits. There follows the network and once uh there is an epoch, quoting I will cover it later. I guess uh when the epoch changes, we need that. It is the time I will cover it now. uh Essentially, there is.

A

There has to be some time when we decide which of all the nodes uh will be validating nodes, to decide that uh we, the the nodes themselves, rank all the.

B

A

Nodes who are currently uh no, they they rank accounts on the network by their stake balance. So there are two types of bands.

A

In here I feel like I'm, I never will get to blocks themselves, but I feel like it's necessary to talk about.

A

Validation in the first place, so these are accounts on the network.

A

A

You can see that this account has uh it. It's also called liquid balance or native account balance on explorer. These are tokens that this account can potentially uh send, transfer or use for attaching to different two transactions. Let's cover it later, and this is a balance which uh this account cannot immediately use. So this account has 33 k near tokens on the liquid side, while have 42 million near tokens on their staking.

A

Staking balance is what we use to rank all the accounts and based on that rank, we will select um some of them. Let's not give dive, do deep dive on that, but we select some of them quite a quite a long list actually uh and based on this stake.

A

We compute the minimum stake that we want to uh for for, like what for a node to have to be.

A

Trustworthy and we call it seed price, so current seed price is at 3.2 million year tokens, and this is why this account is not part of elevator's validating list, because it has less than 3 million near tokens at stake.

A

So there are getting back to.

A

To explore, we can see, there are 59 validators currently.

A

Which are which have more than 3.2 million uh their stick account. um I don't want to get us into specifics, how exactly we compute this value we just switched to another epoch. Actually, uh so the price changed and see price changed for, like the these upcoming 12 hours.

A

B

A

These are 59 nodes which will um progress the network further. They will listen to all the traffic in the network and uh apply certain actions. Do do certain actions uh with with the rest of the same nodes and what what kind of job do they do? They.

A

Essentially, listen up for inputs from users for request for requests to do certain changes on the network. Those requests to make a change is called a transaction, so there are transactions uh which are essentially a request to change uh what kind of change it could be. It could be a transfer like I'm account a. I want to transfer to account b uh x amount of tokens, that's a change!

A

um You you create such a transaction and submit it to to the network, and you can submit it through any any of those nodes. You don't need to go to validators immediately. If you submit to any of the node, they will reroute your transaction to the validators and then validators will include the transaction.

A

Into their current uh bucket that they're currently working on, uh that is a block. So each at every single uh time the there is a bucket where you collect transactions and then a set of transactions gets.

A

Let's say fixed frozen into a block, we produce a block every second, which means the transaction will get input included uh a second lately, usually a second later than it was requested, because we are waiting for other transactions uh potential, other transactions to fill up the block, and then we use this as a.

A

Like you essentially apply transactions in in batch.

A

A list of them and that is called in in blockchains- that's called a block. So why do we need a block? Why can't we just use like we receive a transaction, a transaction? Let's, let's just execute it and apply the change immediately.

A

The reason to have blocks is to uh save up on certain costs of communication from well from different validators.

A

So, instead of communicating information about every single transaction uh to the whole network, uh we just the blockchains usually go with this approach of uh delaying uh for a second to collect a few transactions into a single block and then only communicate information about a block to the network, which will be much faster in terms of throughput.

A

So it's it's again. It's a compromise between throughput and latency. So if you try to immediately apply transaction to the network, it will be super fast, uh but you will not be able to uh process like tens of transactions per second, uh because it will just spam the network and it will be so slow uh with blocks.

A

You cannot apply transactions immediately, so you introduce latency delay to to applying the change, but you can apply more transactions at once. uh A near protocol benchmark shows us that we can use like collect up to a thousand of transactions into a single chart, uh let's let's, let's say into a single block, but with some remarks.

A

um So this is the reason why we have blocks in the first place, what we also have, which is specific to near except blocks. We have chunks, it's they're not represented on explorer's side, because they are internal implementation of near protocol.

A

They are essentially optimization to provide uh like even more horizontal scalable throughput. So, instead of uh imagine, you have two k transactions per second as an input and your your block can only handle uh 100 1000 and you have 2 000 on like on a peak time. So what you? What other blockchains do?

A

They rise the price of like executing a transaction, and this lowers the like the amount, the traffic, because people are not ready to pay for uh for those transactions, but it doesn't help, I would say- and it's quite aggressive at near what we came up with is sharding, and this means that those validators they don't really produce blocks.

A

They essentially collect all the transactions into chunks. So that's the entity that we use here so chunk is what, in other blockchains and it's called block, is a collection of transactions into like this batch. We can have as many of those chunks as possible.

A

As far as you know, we test it with 10 shards, uh which means that for each uh second, there will be uh okay. I will get to it.

A

uh uh Each second will produce uh a chunk in every shirt, so every shard uh produces its own chunk. For this.

A

Second, let's say: let's put it this way for now uh you have 10 chunks and this produces the same second and then we decided to call this this whole thing a block. So a block is the virtual thing. Now it's it's not containing any transactions, it contains chunks, so each block can contain like if you have 10 shards up to 10 chunks in it.

A

Also, given that the nature of the network is that delays could happen or some server could go offline, we don't want to block to delay block production uh waiting for every single chunk to appear. That's why we can create a block with not exactly 10 charge, but less than 10 like it could be even one one chunk, it could be even zero chunks like, uh for example, the the all the validators who are responsible to produce those chunks are currently offline, but the leader who is responsible to come to produce a block is online.

A

Then there is no no other thing for.

B

A

For the validator who is producing the block is to submit a block with no chunks in it uh technically uh on on the in reality, uh we to to prove that you did try your best.

A

While the validator, who is producing such a block with no chunks, included a chunk from a previous, previously known block, so let's get back to the questions.

A

One shard produced one chunk and shorts and chunks, but one block still the consensus in shark produces the chunk, but how the chunk get into the blocks so yeah. So there are two uh two roles: uh the there are chunk chunk producers and chunk producer role and block producer role.

A

All the validators are assigned the schedule to do trunk print production and block production, so throughout the epoch, every validator will be assigned to either produce a chunk or produce a block for a certain uh block heat so about hate is over here.

A

So at this specific height, this validator is expected to to send to to transmit a block to the network.

C

So, like I understand so, the chunk producers essentially have a consensus to create the the chunk uh and what I don't understand, the block producers.

C

How do the block producers agree so, like you can have broke, produce block producers from different charts agreeing? Is it yeah like? Is it or like? How does it like? They still have to have a consensus on the chunks produced by the shards.

A

Yeah, so I'm I don't have like complete picture here like how exactly the consensus works uh over there. What I know is that on the high level, indeed, they they collect the chunks from chunk product producers uh from from shards, essentially and just validate certain uh like headers. They do not call the transactions and the.

C

Proofs yeah yeah.

A

They only evaluate the proofs and then conclude with with their their own proof, for this specific block and that's how they produce a blog. I don't care about transactions in the chunks, yeah.

C

But when you become a validator in a sharded system you decide which chart you want to join because you like deploy the pool for that chart. But the thing is like: are you just a junk producer or you can be a chunk producer and a blog producer or.

A

You can be you you, you will be a chunk producer and blog producer.

C

Okay, so sometimes it can happen that you're, the block producer for the whole blockchain, essentially yeah,.

B

C

It happens that you're, just a child producer for the shot.

B

C

Amazing yep, okay, okay,.

A

C

A

A

So, on explorer side what you will see, if you open a block, you will see a list of transactions. We are skipping here, the the abstraction of chunks completely. uh It is stored in the database, but I I don't see any good reason to over complicate things on explore site.

A

There is a missing part here which will come late, come to it later.

A

That is receipts and we actually are getting there. So hopefully they, the there is. The idea of like producing the block is somewhat clear. I want to stress out why exactly the block needs to be produced even when there is no transactions at all or when there is no um no chunk in it. So you can see there are a lot of blocks with like zeros zero, just one transaction.

A

um Well, when when there is one reduction you may say well, I I could delay this execution for one more second and include that transaction in next one. So there would be two transactions and I don't need to uh you know, create a separate block uh just for a sake or a single transaction, but that would delay this transaction execution by unknown amount of time. Maybe we could limit it up, but overall it's it's not a great experience. It's better to uh apply transaction as soon as possible, so essentially execute transaction.

A

Make the change update the blockchain. It's all synonyms.

A

So, let's get to, let's get back to the case when there is only one that is zero transactions in the first place. So why did we create this block? It's? It seems to be useless.

A

The reason to create a block when there is no transaction, that you cannot prove that there is no transactions like if you are, if you are silent, if you it's your turn to create a block to create a chunk and there are no transactions on your queue.

A

If the validator will be just silent, that would mean that they didn't do their job. uh We cannot really reward them for doing that, uh that that could create various issues with like delay and execution, then other validators will spend more resources to uh to execute the transactions and, but while you will be rewarded with the same amount of tokens at the end of the epoch, so that's why we need to um to create blocks even when they're like empty.

A

Nowadays, it's uh like more it's rarely when the block is empty, uh when mainnet was just launched, it was mostly empty. um So there are these days there are like refinance uh near crowd and rainbow bridge which, mostly like almost constantly producing some changes to the network.

A

uh Let's, um let's see what what else do we have here? So um this is my account.

A

uh I submitted 25 transactions, uh 25 changes to the blockchain, and I received like some somebody submitted two transactions that were targeted in my account, so these are outgoing, where I'm signing the transactions- and these are like incoming- uh I can create uh changes to my own account, so this would be counting twice, uh for example, this one when I create added a new key uh from for my account from my account.

A

So it's uh it's a bit misleading here, but well um that's how it's done right now, um let's open any of the transactions and see what what kind of change we can submit to the network. So, as I mentioned, transactions are getting included with the blockchain uh transaction. Is a sort of a history? Is a your uh is a ticket which you give to somebody who who is applying the change to like a huge registry of data, so this was my ticket, my transaction, which I signed uh to for this another account.

A

um I paid this amount of uh near tokens to for processing my transaction and the the value it's well. It's not very interesting or in this context, so let's keep it out so interesting part is that we always know when it happened. We also know, as like, unique identifier of this specific request.

A

A

Sha 256 uh in base 58 encoding does talk anything about it here. Well, there is dogs, uh so you you may look it up. It might be incomplete. I don't need to double check, actually um a good point for like going through it. um My transaction, like any transaction, can have multiple actions.

B

A

And in this specific case, there is only one action I wanted to transfer six near to this account only one action uh when this transaction uh appears on the network uh and the validator receives us receives it.

A

uh There is going to happen. Some processing and this processing on the uh data side is going to be the following. So it's it's a nice ui uh kudos to dmitry for uh landing it and implementing it in the first place, and now we can easily reason about what's happening here.

A

uh So first thing: what happens with this transaction is that we convert transaction to a receipt so uh internally uh the the whole operation on the blockchain level happens with receipts. We it's an entity that we use it's called receipt. uh It's it's! It's similar thing to a transaction with the only change that they are signed by the world leaders, so they they are not signed by the users.

A

uh They are signed by well leaders and then transferred across the network on behalf of a leader. So while leaders are now in charge of uh of those transactions, so let's see what's what exactly this means. So a validator receive a transaction and converts it to a receipt. So this means that the validator checks, the transaction- is valid to be even processed, so it is signed by me.

A

uh There are not enough tokens to well. No, it doesn't change. It doesn't check for whether it's enough tokens for for the actions, but it checks whether there is enough tokens to pay the fee uh for like.

A

We actually pay more in advance when our transaction gets to the um validator and it it does the this conversion. It charges it over charges us for potential future use uh and e. The validator checks, whether I have enough uh tokens to cover um fees, and maybe I'm not 100 sure it can check for this deposited value, uh which is uh deposited from transfers or from function, calls.

A

But it's it's very simple: there is a simple list of like basic checks, mostly cryptographic. The the most important one is whether the transaction is legit in the first place, whether it's signed cryptographically, signed by my key and by the key that is, uh that does belong to this account and it the the signature, is correct.

A

uh The validator spent so much gas guesses. The unit uh of measure of different, uh like cpu time or uh storage uh or other like resource on the network or like network traffic, is also counted. uh How much like effort does it take to communicate uh this particular event to other validators?

A

um All those fees are configured in the protocol config and that we see that we saw on the genesis uh this uh main genesis file. So there are like uh runtime config. Where is cost.

A

Transaction cost action, receipt creation, data risk creation.

A

And well, I'm not hundred percent sure like how many different costs we have here, um but they're estimated uh with a specific special tool uh where we measure how much uh like cpu time, speed instructions um we needed to perform such an action such action. um So let's, let's get back uh validator. Does this conversion and later converted transaction to receipt and include this transaction in the block.

A

This receipt is going to be executed. Sometime later, it could be executed in the same block if uh receiver is the same as signer, otherwise it will be executed in the next block.

A

As you can see, the block hash with this transaction was included, is 86 with six and over here, and this receipt was executed in this block gk g1. So let's, let's open those two up. So this is one.

A

A

Has the number uh 91 and the one when this receipt was executed when this receipt was transfer, transferring six tokens was executed is essentially in the next block in 1992 block, eight and currently in explorer. We do not display receipts, we only display transactions. uh It's a bug. Well,.

A

Missing feature to display receipts here, we'll need to fix it, but what I want to stress out is that it's not exactly an empty block in this case it has a receipt and it even has like execution result, and you can see that um there is like this receipt is the same. It has the same action six near tokens as in like in our original transaction.

A

So what basically happens is that uh every transaction converts to receipt and this first receipt has the same set of actions uh as the initial transaction. That's the like that that is happening all the time. It's it's exactly what's going to happen with the execution and this uh receipt was executed and it it actually triggered another receipt to be created and executed as well uh this time. So if if this receipt was sent from fraud.near to this, went to the near this receipt is sent from system.

A

There is no such account on the network to fraud it near, and the action is to transfer this very little amount of near tokens. That's kind of weird- and I guess that's um not exactly represented in the ui yet, but it's a refund to what they said happened. While this conversion was has been done.

A

The validator pre-charged my account immediately at this stage and then produced a receipt to refund back unused tokens, so it pre-charged to potentially execute this very complex, potentially very complex receipt, but turned out we don't have. We don't need uh all of those um pre-chart tokens uh for the gas uh we used so little gas, so we were uh refunded by the neo protocol.

A

Again it happened as you can see even further in the history. I guess it's 93rd, it's 93rd block. uh It seems it's again appears uh empty, but it's not. It has this receipt with the with refund thing.

B

A

Is it does it makes sense.

A

uh How the system sign the charge back receipt so, as I said, all the receipts, even this one is not uh signed by for all.near. It's not signed by system.

A

uh These are receipts like these entities are signed by validator key, so well, leader keep here, and it's now validator who is in charge and who, who will be slashed if they are not following the rules and all the rest notes come like checking and constantly checking that the rules are indeed uh applied correctly according to the like near protocol expectations.

A

So if, uh like the the core essence of the the whole protocol that all the nodes only receive the inputs, they never receive outputs. They independently come up with the outputs and create checksums or proofs. They compute a proof of the latest state and only share this proof. If the proof is the same, that's fine! If the proofs, if the proof is different, then some consensus rules kicking and something can be rolled back or somebody could be slashed.

A

uh So there are very like different potential uh turnarounds to um to such situation when proofs do not match- and you cannot just you know, uh submit a proof with without computing the value, because you can't brute force it.

A

D

Yeah it answers my question just wanted to check because, like it has to be signed or verified, somehow that I just wanted to.

A

Check every application has their own key attached to account and fee aligns yeah.

A

uh Well, let's make sure that we are like on the same page in regards to the transaction and receive the outcomes. So what the topic that I covered right now is a transaction.

A

It's it's relation to receipt, and this this thing here, which is currently not represented good enough, I would say, like there is a result and there could be potential logs, let's open yeah. Actually, it's uh let me open some other change.

B

Oh hi, okay, um yeah.

A

So there is a there is not another type of action that could be on transaction, which is a function call method.

A

So it's essentially I mean not functional called method, but a function call or a method call.

A

So when there is a contract deployed on on some account, I can call that some function on that account uh providing arguments and the method name.

A

Arguments are most of the time in json format, but on neon protocol they're not limited to json at all, it could be any binary protocol breach, uses borsch over here. So it's completely unreadable, but it's more efficient than having json to parse on the contract level, and if you would open such once again, not a great.

B

A

There is some other account that I just happened to memorize. I have no idea who the kind of this so sorry, if it's some someone's uh around, but it's useful here, so there is a contract deployed on on the account itself and this account creates a transaction and it wants to call a confirm method on this account.

A

uh I happen to know what this actually means. It means that this nexus.net account has a smart contract which has 2fa implementation to factor implementation. So essentially it happens to stage.

B

A

A

First, you need to add requests and add a request and confirm uh so it's uh like whenever you do where, if, like you, you want.

A

To you want to make some change uh on the blockchain level, um but you want to have a security in place, for example, by also.

A

Providing security code from your sms or any other second factor.

A

uh Device or whatever, so the first stage is that you add a request to your contract, so there is a contract in that implements this two-face process. There is a message, add request and confirm where you add your future request that you want later to execute on the blockchain and then you need to like once you do receive sms or a code from your 2fa device you, so it will submit a second transaction to your account with this confirmation.

A

So very first call is quite simple, so we call a method with a list of parameters, so the request is the receiver will be this one and the action would be transfer this amount of tokens and that's pretty much it so we are. uh We are submitting requested uh like for 2fa for future 2fa.

A

um What this contract does it receives this method, uh these parameters and it just stores these parameters in its local state and returns. You the the unique id- and it also refunds you with some tokens.

A

A

The second transaction which calls com confirm it, says I'm confirming the request id 72 uh and then what happens? We convert this, this transaction into receipt and then execution begins.

A

uh Validators will run this receipt, which is the copy of transaction essentially but signed by validator.

A

This call confirm method produces a cross cross contract. Call, uh it's essentially a separate receipt, so it will. It will produce a separate receipt uh from nexus.near to this account to transfer that amount of tokens.

A

And these two are refunds, they're from.

B

A

So, let's, uh let's probably.

A

Take closer look into multisig contract, so I will link up.

B

A

I just want to for us to.

A

To see so, there is oh yeah, sorry.

A

uh So ed request and confirm it's a method on our smart contract, uh as we saw request, uh was it's a complex structure which includes, like all sorts of things and the implementation that we add request?

A

We do this. We have this request id and we will return this request id. That's all we need to know about the implementation for now. So just to remind you. Where was.

B

A

Add request and confirm.

A

Here is the request.

B

A

B

A

B

A

A

Add request and confirm, add, request and confirm it's a it's. A message name on the contract here is a request, request, multisig, request.

A

Multi-C request has a receiver and actions a vector of actions. So here is the receiver and vector factions. Each action is the thing uh each action here it is so it's a transfer of amount.

A

um I'm not sure where, like why I deposited here, I guess it's some legacy stuff. um So getting back.

A

To add, request and confirm: that's all this method does so it just created a new request recorded on local storage. uh Has this new request id and returns it so 72, as we saw it here? Is this new request id then, when we call confirm.

B

A

So we call method confirm with request: 8072 confirm request id 72. We check that the request id is valid. uh We check some other conditions.

A

We check who exactly.

A

uh Which key uh was used to uh confirm it? Yeah? That's that's a missing part over here in the ui of explorer. We can't really uh understand why it doesn't like what exactly is going on. Why we can't, like just send add, request and confirm and then one once more once more time, just send confirm from the same account.

A

Actually it checks for a specific key that is used to sign that transaction in the first place, and there is a like a list of expected uh keys that need to be um used to sign to prove that there were more than one confirmation and if the converse confirmation is enough, then we remove the request and execute the request.

A

Otherwise, we just insert this new confirmation to the list and you you could set up your multisig to to have like three or more um confirmations uh required here. We only have like two confirmations uh that is enough to confirm and execute um execute the request execute the request.

A

So we basically when we confirm we use the seventh as identifier to find the request from our local storage to later to to execute it, and this happens to be 72nd request- is to transfer six near 6.9 near tokens to this account.

A

Well, I hope it doesn't overwhelm you.

A

I guess we should stop here today, because even though sandy asked about the keys and accounts- and we touched- uh we touched the accounts briefly, the accounts and keys are quite a complicated topic. I may cover it in the next call.

C

I just have a question: this will be sick thing. Is this used somewhere in general, like right.

A

Here, it's you. It's used in wallet so when, when you sign up in wallet and you have it, it used to be a limit of 50 near tokens when you have an account uh and you uh you just created a wallet account uh with 50 or more tokens, it will suggest you to uh protect your account with multisig and while it's needed without multisig, I can open. So somebody can, you know, approach my laptop open, world.near the torque and send tokens whoever is needed.

A

So I like there is no protection here. It's it's fine like yes like and if, even if like we would come up with some, you know pin uh on this page, it doesn't help because uh the attacker could go into local storage, extract the key and do whatever they want to do with my account. Having that key.

C

Where where's the multisig in the wallet, we don't have it right now or we do have. We do.

A

C

A

Yeah, it's it's right. It's embedded into like into wallet uh flows. You can enable it.

A

Account yeah so to factor you can enable it, and then it will provide you with a service to provide to a faith through sms or email. So essentially, wallet will wallet. Helper service will be your second.

B

C

Second factor yeah, I see that's the type of the multisig, so it's not like.

B

C

I thought it's like multiple keys have to sign it like any key, so I could set up like three. I could give one key to mario one give to key to you and then they have multiple.

A

It is the case, it is exactly what you described. Okay, when I set up 2fa in wallet, I give one of my keys with limited access to wallet helper. The only action it can perform with that key is confirm, so it it can only do confirm. Call to my own account.

B

No other calls is, is.

A

Permitted and it can spend tokens.

D

Yeah I haven't realized. Theopha is such a complicated matter in it.

A

Yep, well, it's it's always complicated, it's not only in here, but in here it's even more complicated.

C

Okay, thank you. Thank you because, like it would be nice if you could also deploy like your own, like not use sms but deploy your own multisig, you.

A

You can like it will involve you writing this, the necessary service, but you can do it with this.

C

A

This contract yeah.

C

Okay, amazing, thank you so much.

A

Yeah, so just when you initialize it, you will need to to provide some initial things. I guess and request confirm not sure where initialization is okay, it's a missing part.

A

A

So, but but you can always like go to the code. Yeah.

C

The constructor.

A

New is well it's a single parameter. You only specify how many confirmations you want. uh That's all! uh Let's, let's use this next nexus account and see when it was so how to set up uh 2fa it's it's again. It's all on chain and the beauty fit like it's it's open. You can always look it up, but you can't like do anything about it. Just right there um yeah, so the account was created through wallet.

A

The new key was added, and then this 2fa flow has been done by wallet automatically. It deleted the old keys. So if you have full access key on the account, you cannot really claim that your account is protected by 2fa, because well you.

B

Can you can.

A

Always submit transactions without 2fa, so it deletes full access key, it adds reads the old key and adds a new key for wallet and deploys a contract, a multisig contract to itself to his own account and initially and calls new methods in it. It's an interesting uh transaction, as you can see, there are five actions in the single transaction.

A

It gets conf translated, uh converted from transaction to receipt. The new method is just uh like a function call with parameter new confirmations equal to two, uh the the piece. The necessary piece is to actually have two keys on the account in the first place, so this account has them.

A

uh One is from wallet which uh you can see actually here. So this access key is allowed to call confirm method, and that's that's all. So. It's only allowed to to call this method, and this is the key, the the one that we removed it. It used to be a full access key, but we replaced it with the limited permission, access key to find the function called key, which can do add, request and request and confirm the request and confirm the call, those four methods and that's all it can do so.

A

You cannot submit a transfer transaction anymore because you don't have full access key.

A

You can all only do this add, request or add request and confirm to submit a request and then to a favorable, uh as a second factor, we'll submit another transaction to confirm the execution using this. So the wallet helper will use this key to to confirm your requests.

A

Once you provide the correct uh sms code, hope this makes sense for multi seagulls. Is this and any of all either or every uh miracles? Can you uh elaborate more.

E

Yeah yeah, I mean like um when you want to authenticate sir you've actually answered that question already like. I wasn't clear on whether all the access keys were needed to perform all the operations. So so you wanted to transfer or add what you've already confirmed in this case. So what I just meant was, if you under transfer you would either require like.

E

Was it an either to require at least one key or all the keys to be present so say you were sharing an account with you know like three people, so you would require all of them to authenticate their transaction. That kind of thing.

A

Yeah, I guess I mostly answered the question and in like the the only limitation here that I wanted to mention is that it can't remove like or can it yeah it? Actually, it does look up all the existing keys and remove all function, all full access keys like listed here and then re-add them again.

A

Only allowing to do to perform these calls.

A

Is it possible one second,.

A

uh Can you hear me now.

A

Oh cool, it's possible to add requests on adding another full access. Key.

A

Yes, you can do it, you will edit edit request, then confirm it, and then you will have that access key on your account.

A

Yeah, so it's um it's not a um like definitive protection, uh which you cannot undo. You can't even remove uh 2fa.

A

So on the wallet side, you can submit a request to to to deploy an empty contract or call destroy method. I don't recall how exactly multi-sig is implemented in that regard, but whatever, like you, essentially need to re, remove these keys, this function call limited keys and add the full access keys again. So indeed you can send the request any full access key or whatever you wish.