Skip to content
by Unity Nodes
NEAR Protocol

[Protocol technical on-boarding series] Runtime basics (February 23d, 2023)

about 56:18 long

Nothing is loaded from YouTube until you press play, and then without tracking cookies.

About this video

Join NEAR's community: Website: near.org Reddit:   / nearprotocol   Discord: near.chat Medium:   / nearprotocol   Blog: near.org/blog Twitter:   / nearprotocol   GitHub: github.com/near github.com/nearprotocol Dev Docs: docs.near.org Create a wallet: wallet.near.org/create Apps on NEAR: awesomenear.com Learn to Build On NEAR: near.university Grants & Funding: near.org/grants #Blockchain #FutureisNEAR #NEAR #nearprotocol #nft #dao

Transcript

8,482 words

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

  1. 0:00

    so we're ready when you are Leo can you see my screen yes okay cool so well for today's protocol and boarding we are going to be chatting of front time Basics and in like everything that's needed to like run contracts so running them uh feel free to interpret me literally anytime like uh I'm not going to be able to read the Google me chat because it does not appear on my screen as you can

  2. 0:31

    see my whole screen so just raise your voice and if I don't hear you yell or something uh so feel free to interupt me anytime uh if there is anything you don't understand or if there is anything that I say that you think is wrong like it's possible that I've made mistak in my presentation so some people know better than I in this in this room about some of the things I'm speaking about so

  3. 0:54

    like if you think I'm wrong say it then we can speak about it so the first thing is like what is a contract so our contracts are written in languages that are compiled to web assembly so from the newor cor point of view we execute web assembly contracts and like everything else like whether it's beust or JavaScript is entirely independent of us like it's some things that happen before anything ever reached like

  4. 1:27

    the blockchain so what is web assembly web assembly is a bite code language so when written in textual form it's a list likee a Lis like stack based assom language so uh reverse like like reverse polish notation uh in a list Live Language we will see more example about that later uh it is a compile Target of rust C which allows us to write rust contract under the name wasm 32 unknown unknown uh and it can also be transpiled

  5. 2:04

    from JavaScript to wasm so used by near SDK GS so just so you know like that transpiling is based on quickjs which takes a JavaScript and compiles it to C and then C long that compiles to was to unknown unknown so these are currently the two Targets that our SDK supports we before we also supported assembly script I'm not enti sure whether we still do uh so like as far as I know nowadays we are

  6. 2:36

    mostly supportive rust and JavaScript all of these targets compiled to web assembly so as soon as that compilation is done and that's done by the contract developer like nothing else matters to us it's all like one web as only that's the thing we're going to be executing and I actually hear the Google meet message P so I can have a look or someone can speak I don't know hey uh this is Yun I'll just quickly ask a question um so hypothetically uh is it possible for a

  7. 3:11

    someone to write something in a different language that's not JavaScript or uh rust and compile that in uh web assembly and run it on uh like near as a smart contract yes it is possible literally every language that can compile to web assembly can be run on the near blockchain this means like people can write contract in C uh people can write contracts uh I think micro python can compile to web assembly so people can

  8. 3:48

    write contract in Python uh and probably and like basically any language supported by llvm so uh I don't have any examples like right now now but any language supported by llvm other than rest and C can also be compiled well C++ obviously uh can also be compiled to web assembly and executed on top of our blockchain however we don't give any libraries for that and so it would not be a nice user experience to do so we'll see examples

  9. 4:23

    later and you will understand why like it's not obvious like let's say the libraries are important in order to have a nice developer experience but theoretically speaking yes people can and that's actually how we did it with JavaScript which was not supported and then was supported without like any changes to NE because uh like the near SDK team just developed near SDK GS and it uses the same host functions we'll talk about that later and it just works

  10. 4:59

    the same okay so uh this bite code gets executed by the web assembly virtual machine which is like similar to a virtual machine it has its own address space uh its own stack and that's the thing that executes the bite code so by definition it is completely sandboxed like one one web assembly so long as the web assembly virtual machine does not have bugs obviously but one contract cannot affect anything outside of the web as only virtual machine because the semantics of web as only are

  11. 5:38

    defined in terms of this operation does this on the virtual machine so the issue is like we actually want to do things that are not sbox we also want to like make token transfers we also want to access storage and all that is not defined by the web as only virtual machine the virtual machine literally only defines execution so to do that we have access to host functions uh which allow it to actually do interesting things and we will see examples of that later I

  12. 6:12

    introduced the link to the spec uh so that there are in the slides there is certainly way too much information in there you probably don't have to care but this way the link is easy to reach as soon as the slides will be online so just just a quick question uh on the previous slide so in Rust and in JavaScript you can do plenty of things like networking or reading from the local storage or whatever how does like what happens to those uh I don't know invocations of the

  13. 6:47

    operating systems I suppose when we cross compile to web assembly and then when we try to execute it because this is something that like shouldn't take place in the virtual machine right yes you're right right so this is actually uh what wasm 32 unknown unknown means so uh basically when you so uh he for JS I will only be speaking about trust because JavaScript is the same like we take the JavaScript contract we compile it to C and then we compile it to wasm

  14. 7:19

    32 unknown unknown so it's basically the same behavior but what wasm 32 unknown unkknown means is we compil to the wasm 32 archit which is this bite code with operating system unknown and AI for function calls unknown which means that we have no access to the operating system and no access to Dynamic libraries so what other compile targets would be would be like x86 64 so like

  15. 7:52

    the usual Intel 64bit architecture or IMD 64-bit architecture Das Windows d msvc so access to the Windows operating system function calls and using the msvc compiler like function way of calling functions or XX 64 Windows new eabi for Sig compiled or was or x64 Linux Gabi so that's what like this means and so what will happen if you try to use access to the to use the standard library in a contract is it will not actually compile because rust does not

  16. 8:33

    know how to like take this system call and executing and execute it on an operating system that is unknown doesn't mean that we also cannot use any like in Rust it would be uh crates that at any point depend on like this OS support or the API that you mentioned yes so it means are limited to only no STD crates uh thankfully rust is starting to get quite a good ecosystem of no no standard Library crates uh and uh with the split of allocation outside

  17. 9:13

    so between core which is available everywhere and lid like the standard Library there is aloc which allows to do allocations with v and box and stuff like that and with that like with only core and ack lots of CES are are able to work nowadays so that does not mean every crate will work because lots of crates are still designed with only like STD use case in mind but most big crates in the ecosystem that do not actually need for their operation standard Library

  18. 9:47

    often have like a no STD variant and so they can be used nice thanks and yeah yeah briefly interrupting um so web assembly is a little bit special invest uh in that when in implementing the target uh people have decided that uh it is probably better that uh we make those standard Library functions Panic right and not compile I don't know exactly what the reasoning behind that was but

  19. 10:19

    um typically this will mean that as long as you don't actually call function that access uh these operating system uh resources uh then it will compile and it will run but as soon as you do access those uh system resources that then you will get a panic and the contact to board that's really nice yeah oh that's interesting I didn't know about that thank you and okay for full completeness about compil targets uh there is also the wasm 32- W ASI was the uh Target which is not

  20. 10:56

    supported by our blockchain but is what is usually usually used to execute wasm 32 on host and it executes like with the wasi definition of what and the environment would be um yeah that's interesting like okay we can use STD libraries in rest okay cool uh and was them unknown uh so now we only text examples uh so this is just to give you an idea of what web assembly look like

  21. 11:35

    looks like so this is a mod this defines a module so a module is basically what a we assembly like what a web file is uh so we Define a module that exports one multiply function and that would be a contract a possible contract call uh so not the this specific module is not a contract and we'll see later why that is but like this would be like a a function a contract call which takes two parameters uh two integer parameters

  22. 12:12

    and returns one result and then first we get the first parameter then we get the second parameter we multiply them and the top of the stack gets returned as the result so that's what I was saying where like the syntax is list likee and it actually like executes uh it actually executes the these operations on the stack so it pushes the left hand side on the stack then it pushes the right hand side of the on the stacks and then it multiplies

  23. 12:46

    them so when you take your rust Library it compiles it to some binary that can also have this text representation it's always possible to convert from the binary to the text representation and back using the web assembly binary toolkit which yeah anyway you probably are not going to be needing that but the idea is like this is what we actually execute now some more complex examples I will be skipping like the the boiler

  24. 13:16

    plate outside uh when we take one parameter and return one results and we want to return the minimum between the parameter and 10 so first we push the parameter on the stack we push 10 on the stack we do a comparison and if the comparison was successful then we return 10 otherwise we return X that's like pretty pretty standard stack machine based by Cod so uh the one thing that may be interesting is how web assembly handles

  25. 13:50

    switch cases uh where basically you have blocks and you can break out of blocks so here we get one one local so probably a parameter but maybe a local if the function had no parameter parameters and locals are both indexed the same way so here we had one parameter so local number zero was the parameter and local number one would have been the first local even though there are no locals defined here so it a local can be either a parameter or a

  26. 14:24

    local so we get a parameter we test if it's equal to Z and if it's equal to zero we break so we go outside of the block and if not we set the first local to 42 nothing very interesting just so you have an idea of like what web assom exactly is like this way you'll have seen it once in your life and probably never have to come back to it okay so that's nice like we can multiply numbers but like what's

  27. 14:54

    interesting actually is for a contract to do things that that affect the real world the real world as defined by the blockchain but like that affect the blockchain just taking a number big having the user pay some gas and then returning a number is not like actually useful for any user they could just run the program locally right so what's interesting is as soon as we actually make use of blockchain abilities and for

  28. 15:19

    that we need host functions so host functions are hooks into execution basically the wasm binary runs exactly the same Bode as we were saying but it also has some system called API and here the system is our system the blockchain which exposes these host functions so instead of the usual open close read write Etc connect bind system codes that you would find on Linux instead you have some host

  29. 15:54

    functions that we chose to expose and that we promise will stay valid for all contract execution during their lifetime so these hooks are things that the WM binaries are allowed to execute that can have an effect outside of the WM VM because we Implement them they can have an effect outside so that's the same as when you're running a process on Linux right if you run a process you have access to like the usual XX 664 instruction set and then you can do

  30. 16:26

    nothing like you can only make computer STS and you actually need system calls in order to be able to have an impact on the file system in order to make a network request Etc everything else is like pure computation and does not have any use so in the same way the host functions are the exact list of what a contract is allowed to use and like let's say with I think it was George I didn't see see the face but I think George you were asking um about using

  31. 17:00

    standard Library using uh host uh about using standard Library using crates we could if we wanted to uh Define the the web with the wasi API for near and that would allow us to say for instance like opening a file means looking at this storage key and then we would be able to actually use the whole rest ecosystem now we probably don't want to do that because like that would be like not optimized for blockchain use case so we would need much more thought about it than what I'm saying but like

  32. 17:41

    theoretically we could say like our blockchain has this interface that is the one we chose to expose plus the wasi interface and then the contracts could be compiled with wasm 32- wasi instead of wasm 32 unknown unknown and then they could have access to the whole standard Library API and obviously we would not Implement functions such as network access we would make them always

  33. 18:05

    fail but we could in theory like introduce a file system on top of our storage yes um who who maintains this uh like list what's available and what's not is it this list is currently by mostly by the contract run time team uh and is evolved only through NPS uh so we'll see examples of host functions later and what we add and what we don't uh but yes basically it's like it's it's contract R time who who deals with that mostly I

  34. 18:48

    see thank you so the list of host functions uh for near core so on the execution side the list of host functions is defined in the near VM logic crate which is under runtime and so under maintainership of contract runtime uh so this is basically so I'm saying in the maintainership of contraction time it's not really true because there are all like a lot of storage related things in there too so like let's say

  35. 19:21

    mostly uh so the the near logic crate is the place where we list the functions a contract is allowed to call and then the near SDK exposes these functions in a way that is easy to consume for the smart contract so it's what I was saying earlier that like some host function calls are good because we want to reduce the attack surface to the maximum so we'll have more examples later but just Lally just after but like

  36. 19:55

    the idea is the host function we expose is is the most minimal API we need to expose in order to provide the functionality and then everything that is around making it nice happens in the nearest Decay and that allows all the making it nice part of it to actually run sandbox so if there is a bug in the part that tries to make the functionality nice to the user then it will only affect the contract that was compiled with it and not affect the whole blockchain

  37. 20:29

    uh I've introduced links in the slides same uh there is like the full list as seen by NE SDK and as seen by our wasm VMS that are hopefully the same uh even though near SDK also has helper functions in the list but basically we expose so what happens when we want to add a host function is first we Define what exactly we want to add the minimal API Etc then we Implement that into the near VM logic crate and then as soon as it's exposed we have like the protocol

  38. 21:02

    version that allows contracts to use it uh because it's obviously a protocol change to add a new host function uh then we can expose them from the near SDK so that smart contracts can start using them easily so uh what is there as examples of host functions so the first examples will be the the vious ones we obviously need so input allows a smart contract to receive arguments from the outside world

  39. 21:35

    so it's not as a whole con that any contract in in R will ever actually use manually it's used by the X contract proog micro and it's like magically passing the the arguments and sending them as function arguments we are not receiving direct function arguments in terms of wasm because was function calls only support like 32 and 64bit integers basically so that would make no sense

  40. 22:06

    for a contract that needs to for instance get a data structure like or pass a Jon and that would just not work so in order to do that we have that input smart host function that allows the smart contract to just say please put my input in my memory at this place similarly value return allows the smart contract to return arguments to the outside world so these two operate on raw bytes so that's what I was saying when I said minimal API like inputs

  41. 22:39

    takes a slice of n bytes and value returns takes a slice of n bytes and that's all they do so basically on the contract Trend time side it's hard to get it wrong and then all the paring distalization Etc happens from the contract itself so that's also because in practice it would be really hard to do the deserialization on the host side because types do not translate well between outside the VM and inside the VM but it's also because this way all the

  42. 23:12

    distalization is done by the contract itself and so secured by the sandbox now the smart contract can get inputs and return outputs it can also get information on the accounts involved in the call there is like signer account ID uh uh current account ID and there is a third one which I forgot uh destination account ID or something like that uh so there are a few account ID uh host functions that give the account ID

  43. 23:45

    involved in the call and this isn't necessary for any fible token things because basically like f tokens need to know who is coding the function to know who is paying the token yes I heard something oh it was just uh Marcelo saying it's a predecessor account ID he thinks predecessor thank you uh then there are the storage host functions as I said like we it allows interacting with the storage and then I mentioned helpers that make things nicer to use so for instance near SDK also has

  44. 24:27

    state helpers that are basically like storage but with a specific key that is state so that's one place when usdk is exposing more than the API we expose from the blockchain because it makes the life of contract developers easier and then there are the promise Etc uh host function calls that allow creating more receipts so to do cross contract calls or anything else made possible by creating further receipts basically so I'm not going to talk more

  45. 25:02

    about that Jacob already talked about it on January 6 so feel free to watch the recording if you didn't yet uh okay now there are other things that we are implementing as host functions and it's not obvious that we need them like we got input output storage and we are able to do cross contract call so what the matter in turns out we need other things so there first there are information that only the blockchain has

  46. 25:34

    like the block index called block height by near SDK uh the block index Returns the height of the block so that's information only the blockchain has there's also used gas that Returns the amount of gas already used so we'll talk more about what used exactly means later on but that Returns the amount of gas that has already been used by this contract Cod so that's the the kind of

  47. 25:58

    thing that could be computed by the contract developer but would be really hard to compute and it's easy for us to expose it for the contract developers usage so why not just do it and so we expose this very simple function that allows the user to know how much gas has already been used by its contract so that it can decide like how much gas to send up to send on a new receipt for in stance and then there are host functions that are like purely for performance so for instance we have a sh

  48. 26:29

    256 host function that computes a sh 256 and that is needed because basically implemented chat to statistics in wasm would make it much slower because our wasm virtual machine is not optimizing so so basically when we execute it it's does not have access to anything like simd it is just like the the minimal thing that allows us to run securely something so executing mm is safe and it's reproducible and it's all nice but

  49. 27:08

    it's the the issue is it's slow especially for compute intensive things like Computing a hash so that's the kind of host functions that we can add on an app so recently we have been looking at adding uh I don't remember which signing scheme exactly uh but we have been looking at at adding a new signing scheme to to the host function list if I remember correctly so that's the kind of thing we can add uh if there is a significant

  50. 27:34

    performance benefit and a well established use case so we can add them but we need to remember that there is a cost in that because if we add a function we need to support it forever because if we remove it contracts will stop working so it's not we could decide to do it but that's probably not something we'll ever do so as soon as we add one host function we need to support it forever and that's the cost we need to keep in mind when we decide to add something for performance

  51. 28:05

    reasons yes I heard someone speak beep uh sorry uh I have a two question regarding block index uh one is um at this point when a uh when user when when this host function of a block index gets called is it already determined mean that this is actually going to be I mean is there any case where this um the block will change or is it like either included in this block or it'll it'll be just discarded and just doesn't get included forever to the best of my knowledge as

  52. 28:45

    soon as we start executing a contract call we know in which block it will get executed and if we don't manage to execute it in time for that block then we we just drop it forever and okay if we if we need to execute it again then we execute it like if if we actually need to execute it because it's a receipt then we will start from scratch on the next block I see um and my second question is how can this information be

  53. 29:18

    useful to I don't know caller how do they use it so honestly I don't know and Sarah this is the place where I'm sorry but we will have to make the meeting recording private because it is very useful for an attacker so there are other things that an attacker can use but well maybe I don't know if we need to make it private actually because it's not any actual like security vulnerability but like it's like block index and the fact that

  54. 29:49

    we drop receipts in and the fact that we drop receipts when we don't actually manage to execute them within a block means that as soon as we get an another charging that makes one receipt miss the block we need to reexecute the whole receipt and that means that if we have one receipt that takes more than 1.5 seconds to execute then we will stall the chain and that's bad so uh block

  55. 30:20

    index as well as random seed which gives a random seed so like there are also functions that actually have a reason to be there that like have the same behavior but block index is the kind of primitive that in my opinion are more useful to an attacker than to a user now I think some things like probably Rainbow Bridge and other cross chain bridging probably need to use things like block index in order to validate the cross chain transactions but I'm not entirely sure

  56. 30:58

    about that be a way to measure time like unless there's other better ways to measure time so there is also block time stamp uh which is like block index but Returns the time of the block uh which is better but yes has the same the same security issues yes you're right it can be used to measure time so I guess like my natural question would be then if there isn't too much benefit to users and why are we even

  57. 31:28

    exposing this I don't know so block index in particular I don't know uh block time stamp is as said by George to measure time and random seed is used because contracts sometimes just need a random seed though I'm not entirely sure if there are good use cases for random seed given that the randomness can be controlled by the last valid can it I'm not sure uh I think a validator can decide which by deciding

  58. 31:59

    which transactions to include probably can affect significantly the random seed of the next block but I'm not entirely sure about no because because we are using like verifiable like uh pseudo random verifiable function so we are safe I think unless a sufficient number of validators collude we actually have good Randomness now I'm not sure there are I well let's say I cannot think of

  59. 32:31

    good use cases for random seed but I'm pretty sure if we added it at some point it's because someone asked us and if we have block time stamp now my guess would be we first had block index and then we thought it would be measured to measure Time by using the block time stamp so we introduce block time stamp and nowadays block index is probably not that much used but it's still like there because

  60. 32:57

    we need to support it forever because contracts may be using it maybe in a place that does not actually even use it but they may be just linking to it and then they would stop running if we removed it thank you I mean I I I don't want to spend too much time on this just um I was wondering if if this is like just set set in stone that like we have to maintain it even if there's like security vulnerability or if there's any way for us to like somehow

  61. 33:28

    lifted uh to reduce yeah issue so the first thing is like I don't think removing it itself would entirely reduce the issue because we would still have block time stamp and random seed that are probably needed by contract in the wild so yeah I I don't think we could reduce that issue significantly by removing it now what we could do would say would say be able what we would be able to do would be for instance say it always return zero and that would work

  62. 34:04

    but we would still need to have some function that return returns something of the same type otherwise contracts even unrated would break like basically any contract that does not uh that did not run all the optimization steps we mentioned probably links to block index and so would stop running if we just removed it but we could make it always return zero thanks problem just to clarify I'm not

  63. 34:36

    George I'm vat oh sorry no worries yeah from only the voice it's hard to tell um so uh used gas we talked about it chatu 56 and we have log functions that allow for logging so for this I if someone wants to talk about them I would love to let you speak because I don't actually know where we log to like it's written in the documentation of near SDK that we log that the logs are stored in the

  64. 35:08

    blockchain uh I don't know what that means because we probably don't keep it in the chain storage so yeah if someone knows what that means I'm open to hearing more about it I think you can see it in the Explorer but also in New social I believe they will be logged in the uh developer console okay this was awesome actually during the hackaton okay so so it logs so so basically it logs and then we don't actually store it to the blockchain but the tools that are

  65. 35:43

    developed to use logs allow to fit them from the Explorer and such okay thank you um okay so we are able to do everything but now we must do everything in a way that does not actually cause problems uh oh yes sorry so not yet that's the next one so we can do everything with wasm with wasm and host functions but like how does it work like how do things to work in practice what does the code look like so we have a few wasm VMS uh that we glue together with

  66. 36:23

    the near VM Runner crate so the near VM Runner crate just like exposes a consistent interface to our wasm VMS so you will ask why do we have multiple wasm VMS and there are multiple reasons the first one is we need two right now right now we have wmer 2 which is our optimized production VM so it produces web assembly code that is not fast as we mentioned when we were speaking of chatu 56 the the code is definitely not optimized but it does compile fast and

  67. 36:58

    what we actually need is for to compile fast and not to execute fast because each contract call can trigger a recompile because of reasons basically like on each new core update we can trigger a recompile basically like we need to recompile all contracts and we do that lazily on each contract call so what we need is a a comp VM that runs fast sure the faster it runs the better but that also compiles fast because each contract call can be a full recompile

  68. 37:32

    and that happens once per contract per new core update basically not really every update but let's say most updates or some updates basically every time some constant in the source code changes and that's when we make changes to the VM but one more two which is optimized uh for production only supports X8 x86 64 machines so that means that it does not work on M1 Max and for that we introduced wasm time which is way too

  69. 38:07

    slow to compile for production usage like it's literally 10 times slower than wasma 2 but it's support M1 Max so for development we use wasm time as soon as someone uses a Mac uh now that is what we would love to support but we actually need to support other things because of replayability so we also have wmer zero which is an old VM that is used for protocol versions before version 48 so it was not used since late

  70. 38:38

    2021 uh but that we need to keep supporting for replayability reasons and that will make me ask I think you probably have discussed that with mean uh protocol on broading like what a protocol version is but there is no recording so do you actually know what protocol versions are I will take that as a yes okay we don't have me here okay yeah no but I mean like if anyone here does not know then if people

  71. 39:10

    do know I'm good and if people who watch the recording don't know well feel free to ask on zulip so uh so wasmer zero and old VM used for protocol versions before 48 so it's been a bit more than a year now like a year and a half approximately uh but we need to keep it around for replayability reasons and soon we will have near VM uh which has all the improvements we did on wmer 2 in

  72. 39:38

    the last year and a half uh but that will be one more wasm VM because we basically let's say there are two reasons here we don't first we don't want to introduce the concept of a protocol version inside a wasm VM because that would be a mess basically like architecturally speaking the code would become a mess so we would much rather avoid that and there are also like organizational reasons that

  73. 40:08

    currently make it hard even if we wanted to to do it when we will have new VM we will be able if we want to to introduce like protocol versions into it but my hope is uh we will have been able to make support on limited replayability more on that in I don't know what time it is uh well more on that soon uh on the next meeting just after the end of this onboarding because this is the topic of today's discussion uh so hopefully we will have made progress on limited replayability

  74. 40:40

    and that will no longer be a problem basically sorry um kind of clarification question with the uh limited play replayability in place what will be the uh VM we will have to maintain from so if with limited replayability in place right now we could remove wasmer zero so I'd say that's probably a few thousand line of codes right as of today uh and a good number of tests too that we would

  75. 41:10

    no longer need uh so today if we introduce limited playability we can remove wo zero when near VM lens we would also be able to remove wro too so basically with limited replayability we would only have to support two VMS and if it's limited to one replayability two VMS if it's limited to two replayability three VMS during the times where we are going through a protocol switch a protocol

  76. 41:39

    upgrade but yeah we can talk more about that in a few minutes tens of minutes I don't know what time it is and yeah yeah in a quarter so we can talk more about that in a quarter and I think that will be more on the topic then okay so that's how we actually get our code to run so we have the near VM Runner crate that basically takes all the information from the transaction run time and Proxes it through to the right wasm VM so wasmer 2 wasm time wasmer

  77. 42:24

    zero and near VM depending on the protocol version and the architecture is currently running on so it will run on wasm time on M1 Max because M1 Max are not supported as validators anyway and then depending on the protocol version it will use wmer zero to on your VM now the question is like how do we get things to actually work like we don't want to allow for a contract to infinite Loop and like block our

  78. 42:53

    blockchain forever so in order to do that we charge for gas and that's the easy solution the solution everyone is doing but the one that actually works so there are other subtleties to things we do like stack Overflow prevention but the main thing and the thing users are actually concerned about is usually gas they don't care that a contract cannot recurse like 10,000 times towards itself usually that's not actually a need for contract developer what people care

  79. 43:22

    about is gas how much we charge it how we charge it Etc so there are different types of gas uh the types of gas so these are names for gas as seen by contract time uh outside of contract times there are other kinds of gas that are used in ways I don't personally understand so inside contract time we have prepaid gas which is the gas that the user paid for the transaction to execute and any guas that it is not used by the end of the

  80. 43:55

    transaction action will be refunded and I should have written that non-burnt gas and not non-used gas sorry about that I will fix the slide before uploading this is non burnt gas uh then there is the burnt gas which is the gas that was already burnt when executing the contract so I will talk more about that on the next slide but basically when you execute the contract you burn the gas while you go through it

  81. 44:21

    and you can also promise some gas so this is the gas that you attach to further receipts so using the promis host function calls this gas gets attached to the receipts and then the receipts will be able to burn through that gas that has been promised to them there is used gas so the one return by the used gas host function which is the sum of burnt gas and promised gas now what when I said I should have

  82. 44:47

    written non-burnt gas will be refunded because you can a contract can promise more gas to another contract than the other contract will actually use so this means that basically you have one contract it burns some gas it runs a few other contracts each of these contracts burn burn some gas so first the contract cannot burn plus promise to other contracts more than it was prepaid itself and the promised gas to each of the contracts will become their prepaid

  83. 45:19

    gas and then at the end of the day when all this has been executed we sum all the burnt gas on all the contract calls and that is the gas that will actually be paid by the user all the non-burned gas will be refunded yes I heard someone um so it sounds like only prepaid gas is a constant and all the other things are just keep changing depending on where like you're at right yes exactly and um used guess doesn't sounds like it

  84. 45:53

    is actually used because it includes promised guess is that correct yes okay you're right the name is wrong but it is the name of the host function call so we cannot change it unfortunately so then there is the matter of gas prices so in our white paper we promise that we charge gas at I don't remember what rate and then we can adjust that a part but we have not currently implemented that but like let's say in our current

  85. 46:31

    white paper we have that promise about like what the gas price is about well it turns out that we don't actually charge that amount to the user even though the the formula does compute some gas price we actually charge for more than that gas price instead we charge for the pessimistic gas price and the pessimistic gas price is needed to deal with the reips being delayed and the fact that the gas price can change while the receipts are being

  86. 47:00

    delayed so imagine you have one contract that gets 300 to gas and that contract just calls itself it only recurses towards itself and it does very little work that contract will basically take lots of blocks to actually execute and that means that by the time the last receipt of the contract executes it's very possible that the gas price will have significantly increased so in order to avoid undercharging for gas at that point we

  87. 47:36

    at the beginning when the user prepays for gas we charge the user the pessimistic gas price which is some formula that basically overestimates the price the user could need to pay in the wor St for the contract calls itself now that's usually not a problem because that amount at 300 Ras is usually pretty small even even if with the full pessimistic gas price so users don't care about it and they will be refunded all the gas PR so basically the difference between the pessimistic gas price that they paid and the actual gas

  88. 48:14

    price of the receipt they executed will get refunded so they don't actually have to care okay so how do we actually burn gas now that's the one part that construction time is most concerned about because the other things are more about transaction run time where we go get delay when receip and we promise gas to that receipt so contract R time itself is mostly concerned about how we

  89. 48:47

    burn gas and there are two ways for us for a contract to burn gas so the first thing is when a contract calls a host function call that host function call will burn some amount of gas as part of its spec so I know the current like most Troublesome one of these is the touching trode cost which is uh a cost that makes storage operations basically storage operations burn some amount of gas as part of their

  90. 49:20

    specification but that amount of gas is really hard to compute because it depends on the exact state of the try at the time the function call is executed so basically depending on unpredictable things the price of the storage host function SCS can vary quite widely so these ones are the ones that are most Troublesome but most of the host functions have a set gas price like sh56 has a set gas price and that's gas

  91. 49:52

    price that stay in stone and will probably never change until we require more advanced hardware and can get the price lower so that's basically we burn gas based on the amount of computation that has been performed or computation or IO or everything else that's another topic that we can discuss later uh in the production discussion slot probably whether we should burn gas differently for these different ways but right now

  92. 50:22

    what we do is we burn gas for any resource we use as part of contract execution so nothing in the network because contract execution does not use the network but as soon as we touch the storage as soon as we compile what not compile compilation let's put it aside as soon as we touch the storage or as soon as we use CPU to execute the contract we burn gas I'm saying we put compilation aside because we charge for initial contract

  93. 50:54

    deployment so the first time we push the contract but then as I was saying before if we update NE core then we need to recompile the contract and that will not really actually be charged for we we are going to charge for it indirectly in the H function call price but we are currently assuming that that is a cost that is like averaged to zero over the number of uses of contracts which may or may not be true and maybe there are attacks on this

  94. 51:29

    front too where like just trying to make us compile more stuff I'm not entirely sure I have not gave much thought about that uh but basically like contract compilation is not really charged for all the time it's charged for initially when we first deploy a contract but then let's say it's only charged for by the stake that is needed to keep the contract on the chain and that's the only way we charge for the recompiles that need to

  95. 52:02

    happen when we have a near cor update okay so I talked about host function calls that burn some amount of gas as part of the spec there is also some gas that we burn for each wasm operation that gets executed so there are two ways this happens what we do today and what we will do as soon as we get near VM so what we do today with wmer 2 is that we compile we compute the burnt gas for

  96. 52:32

    the wasm contract execution based on the wasm towm instrumentation that was developed by par and that instrumentation charges gas half hazly uh we have one non security issue about it uh I think we've completely burned any opportunity to get that recording public already so let's speak about it so for instance uh the locals are not charged so all the all the all that is done to all the work that is done to initialize the locals of a function call

  97. 53:07

    is not charged for uh actually I have not checked whether the latest versions of the parity instrumentation fixed that maybe it did hopefully it did if not we should probably report that to prority because their blockchain would be vulnerable to that attack but anyway uh that gas instrumentation basically has its own concept of met block and basically what you see when you call used gas today is not necessarily the gas that has already been used it can

  98. 53:41

    include gas that will be used soon and that has already been charged for by the parity implementation so basically this has a number of troubles uh plus it's not actually defined like what it actually charges is not actually defined and like it's just look at the code specification but it's what we do today this plus uh memory overflow pre stack Overflow prevention uh and a few other

  99. 54:12

    things is called the contract preparation step today so today when we compile a contract first we prepare it which means we prepare a new wasm contract that also charges for gas and then we compile that new was contract using WMA 2 now with near VM we will be lending the work that has been done on finite WM with Simas and this will be our own gas metering uh imp implementation that is

  100. 54:41

    based on a strict specification so what we started doing and especially s started doing is write a specification that says what we want to charge and when we want to charge it and so now with near VM used gas will actually represent the amount of gas used until just before the used gas function po we will also no longer be charging for gas in a wasm towm instrumentation but rather like basically charge for gas

  101. 55:13

    directly from wasm when we compile from wasm to XX 64 uh that should improve performance quite significantly because we will no longer have to have things like uh reexport so let's just yeah that's not important but like for performance reasons this will probably significantly improve the performance of preparation step which is the only basically the only part of the contract that we actually control most of the contract is wasm that we do not have any

  102. 55:44

    control on but the wasm towm instrumentation like the gas accounting and the stack Overflow accounting are the two things that we actually have control on and that we can optimize on behalf of contract developers because they cannot do anything about it yes I heard someone or is it just maybe it's just my slack saying in 10 minutes we have a meeting oh yes it's because we have one minute left well that's good because this was the last slide so we have one minute left too late for

  103. 56:18

    questions but if you have something feel free and then we can jump to the discussion slot well that was perfect timing so see you soon then bye thank you