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

Captions as YouTube publishes them, usually machine-generated, so product and people names can be misheard.

1. 0:06

   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 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

2. 0:56

   like are available we even have public archival rpcs because these uh rpc endpoints only store five epochs they don't store the whole history for like for a reason of saving storage 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

3. 1:42

   more mainnet rpc instances to serve recent data and just a few instances with the whole archival information so whenever 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 uh if you are not very familiar with like different tooling you can use postman or carl all the examples mostly feature this http

4. 2:24

   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

5. 3:02

   you can see it reports the version of the binary rhyme there the protocol version and various information over there useful section is sync info which which tells at which block the current node 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

6. 3:44

   have latest data yet it is still catching up with the network 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 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

7. 4:22

   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 uh the useful part here is that uh this point also returns

8. 4:58

   you epoch start heat so you know where the e when e-book starts uh so let's uh check it out um or magnet validators and we pass no so here we are this is uh 3 36 uh million 690 is the block where

9. 5:59

   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 oh it's in severe genesis over here in genesis we 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

10. 7:02

    on it's if block production is exactly one second it is 12 hours uh it represents 12 hours uh for one 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 yeah now i guess we are ready to dive into block specifically so do we want to start with blocks uh one sack i need to think about it um yeah let's start with blocks so

11. 7:51

    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 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

12. 8:38

    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 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

13. 9:14

    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 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

14. 9:53

    as a sub process uh it runs near core in different thread while doing some other work in in some other threads 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

15. 10:40

    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 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

16. 11:25

    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 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 uh nodes who are currently uh no they they rank accounts on the network by their stake

17. 12:20

    balance so there are two types of bands in here i feel like i'm i never will get to blocks themselves but i feel like it's necessary to talk about validation in the first place so these are accounts on the network like 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

18. 13:08

    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 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

19. 13:58

    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 we compute the minimum stake that we want to uh for for like what for a node to have to be 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

20. 14:53

    so there are getting back to to explore we can see there are 59 validators currently 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 um and these are 59 nodes which will um

21. 15:55

    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 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

22. 16:46

    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 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

23. 17:24

    and then validators will include the transaction 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 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

24. 18:21

    waiting for other transactions uh potential other transactions to fill up the block and then we use this as a like you essentially apply transactions in in batch uh 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

25. 19:08

    the reason to have blocks is to uh save up on certain costs of communication from well from different validators 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

26. 19:44

    to the network which will be much faster in terms of throughput 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 you cannot apply transactions immediately

27. 20:25

    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 um so this is the reason why we have blocks in the first place what we also have which is specific to

28. 21:09

    near except blocks we have chunks it's they're not represented on explorer's side because they are internal implementation of near protocol 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

29. 21:55

    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 they essentially collect all the transactions into chunks so that's the entity that we use here so chunk is what in other blockchains

30. 22:43

    and it's called block is a collection of transactions into like this batch we can have as many of those chunks as possible 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 uh uh each second will produce uh a chunk in every shirt so every shard uh produces its own chunk for this second let's say let's put it this way for now uh you have 10 chunks and this produces

31. 23:32

    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 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

32. 24:12

    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 then there is no no other thing for

33. 24:44

    um 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 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 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

34. 25:31

    yeah so there are two uh two roles uh the there are chunk chunk producers and chunk producer role and block producer role 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 so at this specific height this

35. 26:12

    validator is expected to to send to to transmit a block to the network um 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 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 yeah so

36. 26:52

    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 proofs yeah yeah they only evaluate the proofs and then conclude with with their their own proof

37. 27:29

    for this specific block and that's how they produce a blog i don't care about transactions in the chunks yeah 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 you can be you you you will be a chunk producer and blog producer okay so sometimes it can happen that you're the block producer for the whole

38. 28:02

    blockchain essentially yeah and sometimes it happens that you're just a child producer for the shot okay amazing yep okay okay cool so let's let's move on um 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

39. 28:43

    over complicate things on explore site there is a missing part here which will come late come to it later 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

40. 29:31

    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

41. 30:05

    soon as possible so essentially execute transaction make the change update the blockchain it's all synonyms 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 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

42. 30:46

    it's your turn to create a block to create a chunk and there are no transactions on your queue 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

43. 31:34

    need to um to create blocks even when they're like empty 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 uh let's um let's see what what else do we have here so um this is my account

44. 32:23

    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

45. 33:07

    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

46. 33:56

    registry of data so this was my ticket my transaction which i signed uh to for this another account 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 it's a sha 256 uh

47. 34:49

    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 uh 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

48. 35:36

    and the validator receives us receives it 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 uh so first thing what happens with this transaction is that we convert transaction to a receipt so

49. 36:21

    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 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

50. 36:59

    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 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

51. 37:36

    whether there is enough tokens to pay the fee uh for like um 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

52. 38:23

    from function calls 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 uh the validator spent so much gas guesses the unit uh of measure of different uh like cpu time

53. 39:04

    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 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 transaction cost action receipt creation

54. 39:49

    data risk creation 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

55. 40:34

    block 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 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 or 8606

56. 41:36

    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 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

57. 42:25

    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 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

58. 43:09

    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 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

59. 43:50

    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 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

60. 44:41

    pre-chart tokens uh for the gas uh we used so little gas so we were uh refunded by the neo protocol 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 um is it does it makes sense uh how the system sign the charge back receipt so as i said

61. 45:36

    all the receipts even this one is not uh signed by for all.near it's not signed by system 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

62. 46:14

    correctly according to the like near protocol expectations 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

63. 47:02

    consensus rules kicking and something can be rolled back or somebody could be slashed 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 might read yeah it answers my question just wanted to check because like it has to be signed or verified somehow that i just wanted to check

64. 47:52

    every application has their own key attached to account and fee aligns yeah 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 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

65. 48:30

    and there could be potential logs let's open yeah actually it's uh let me open some other change oh hi okay um yeah so there is a there is not another type of action that could be on transaction which is a function call method so it's essentially i mean not functional called method but a function call or a method call so when there is a contract deployed on on some account i can call that some function on that

66. 49:19

    account uh providing arguments and the method name 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 example um there is some other account that i just happened to memorize i have no idea who the kind of this

67. 50:12

    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 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

68. 50:58

    let's open up 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 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 providing security code from your sms or any other second factor uh device or whatever so the first stage is that you add a request to your contract

69. 51:56

    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 so very first call is quite simple so we call a method with a list of parameters

70. 52:41

    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 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 the second

71. 53:31

    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 uh validators will run this receipt which is the copy of transaction essentially but signed by validator 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

72. 54:20

    from nexus.near to this account to transfer that amount of tokens and these two are refunds they're from system um so let's uh let's probably take closer look into multisig contract so i will link up multithick i just want to for us to to see so there is oh yeah sorry

73. 55:27

    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 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 it add request and confirm

74. 56:14

    here is the request let me make it side by side so 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 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 um i'm not sure where like why i deposited here i guess it's some legacy stuff um

75. 57:20

    so getting back 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 confirm 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

76. 58:20

    we check who exactly 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 actually it checks for a specific key that is used to sign that

77. 59:00

    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 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

78. 59:48

    uh required here we only have like two confirmations uh that is enough to confirm and execute um execute the request execute the request 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 well i hope it doesn't overwhelm you

79. 1:00:46

    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 i just have a question this will be sick thing is this used somewhere in general like right 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

80. 1:01:25

    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 so i like there is no protection here it's it's fine like yes like and if even if like we would come

81. 1:02:14

    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 where where's the multisig in the wallet we don't have it right now or we do have we do have it okay yeah it's it's right it's embedded into like into wallet uh flows you can enable it account yeah so to factor you can enable it

82. 1:02:59

    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 uh uh second factor yeah i see that's the type of the multisig so it's not like three is 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 it is the case it is exactly what you described okay when i set up 2fa in wallet

83. 1:03:39

    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 no other calls is is permitted and it can spend tokens yeah i haven't realized theopha is such a complicated matter in it yep well it's it's always complicated it's not only in here but in here it's even more complicated okay thank you thank you because like it would be nice if you could also deploy

84. 1:04:18

    like your own like not use sms but deploy your own multisig you you can like it will involve you writing this the necessary service but you can do it with this contract with this contract yeah okay amazing thank you so much 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 um okay

85. 1:05:06

    so but but you can always like go to the code yeah the constructor 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

86. 1:05:44

    just right there um yeah so the account was created through wallet 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 can you can always submit transactions without 2fa so it deletes full access key it adds

87. 1:06:23

    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 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

88. 1:07:10

    to actually have two keys on the account in the first place so this account has them 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

89. 1:07:44

    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 you cannot submit a transfer transaction anymore because you don't have full access key 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

90. 1:08:23

    helper will use this key to to confirm your requests 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 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

91. 1:09:01

    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 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 yeah i guess i mostly answered the

92. 1:09:24

    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 only allowing to do to perform these calls is it possible one second uh can you hear me now oh cool it's possible to add requests

93. 1:10:21

    on adding another full access key yes you can do it you will edit edit request then confirm it and then you will have that access key on your account 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 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

94. 1:11:09

    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