Fluence Labs Wasm in Web3, 13 Oct 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Maksym Zavershinskyi, Near – Wasm at Near

Description

Speaker: Maksym Zavershinskyi, core developer at Near
Topic: Wasm at Near

Near https://near.org/
Wasm in Web3 workshop https://avive.github.io/wasm_on_the_blockchain_2021/#/

A

Hey everyone, my name is max. uh Just like anna told you, um I'm a head of engineer and engineer, and uh for those of you who don't know, nier is a sharded proof of stake. Blockchain, with a special focus on developer friendliness and um sharding is just one of the ways why how we achieve developer friendliness because charting allows us to be scalable. You know high tps, low confirmation, time, cheap transactions and so on.

A

But another way how we achieve developer friendliness is by using a webassembly virtual machine, because webassembly allows people to develop contracts in a large variety of languages.

A

So currently we support two languages, um rust and assemble script, so most of you are familiar with rust and most of the web assembly enabled blockchains. They actually use rust as their primary smart contract development language for many good reasons, so one of them is that uh rust is the first class citizen as a web assembly language, um not surprisingly, because uh the community that develops wasm and rust is heavily overlapping. So it's a frequently the same people who work on rust and wasm.

A

Also rust is a very safe language, as we all know has drawn typing and lifetimes and prevents all kind of ways of shooting yourself in a food.

A

So that's why we default to rust as our primary smart contact language, but we also allow people developing an assembly script and for those of you who don't know assemble the script is a dialect of typescript.

A

It has been developed by a small group of people that we are the biggest sponsor of, and what they're trying to do. They try to get the right balance between having a developer friendly language uh for uh for people coming from development, mobile development. So many people come in from web development they're already familiar with typescript, so assembly script is just a dialect of typescript.

A

It looks almost exactly the same as typescript, but it has some extra annotations for uh type safety and whatnot, and it tries to also be as close to have assembly as possible. So it tries to be easier to compile to our symbol than typescript and many people. Many developers come into our blockchain they're, with only the knowledge of typescript they're able to develop an entry and a centralized application.

A

um Just in typescript. You know like write a contract, an assembly, script, front-end and typescript. You know they deploy it on a minute in a matter of minutes or hours, depending on the complexity of their project.

A

uh The other two languages that we are um gonna support very soon, um as our smart contractor development languages is green and sick.

A

uh So so, for those of you who don't know, grain uh grain is the very recent language um that uh gained quite a lot of popularity uh because it tries to be a web development focus language but as a language, that's also very easy and a native uh easy to compile term assembling native to us native to web assembly development.

A

We are also sponsoring them and they have already and a better sdk on near that is going to soon to be productionized and ingrained also strikes really good balance between like rust and typescript kind of language. It doesn't have manual memory management, which is kind of a strength of rust because with manual memory management, you don't have this spikes of cpu usage when your garbage collector kicks in, um but for most of the languages. They're going to explain to you later that have non-manual memory management.

A

We actually just disable garbage collection, because smart contracts are short-lived anyway and we can afford to never delicate memory in the first place.

A

So the grain is the case coming very very soon in the next week or a couple of weeks and zig is another language that we've been developing as decay for uh zig is also quite popular. It compiles tub assembly quite easily and um yeah, so this we're gonna have four languages um as a smart contract, which is a near blockchain soon. So the question is: um how many languages are we going to have in the near future?

A

What are our plans and our plans us to have like every single language that compels to have assembly and every language that we can lay our hands on as language for smart contract development and near, and uh it's just a matter of time and the matter of the resources but we're gonna get to all of them?

A

uh We have already been experimenting with c plus plus python java go, um and there are various reasons why we're not we don't when we don't have sdks for all of them, uh specifically with c plus plus, is because uh we are intimidated by its complexity, specifically of the m script, and I'm scripting has been around for quite a long time.

A

It's quite a big code base, so once we get more uh clarity and confidence with username scripting we're going to have c, plus plus sdk on near java python and go turn out to be very heavy in the compilation to web assembly, specifically python programs, their order of magnitude larger when compiled to have assembled than equivalent programs written in rust, and that's because python is not meant to be compiled to webassembly.

A

It has pretty heavy runtime and the contracts that I would usually be like hundred thousand bytes in size. They become like 2 megabytes in size when compiled when written in python and compiled webassembly, but we'll we'll figure something out in the future. We might narrow down these languages. You know again use some kind of a dialect uh to make them easier to compile to web assembly, or we might even raise the minimum the maximum contract size on on near blockchain to be able to accommodate all of these languages.

A

So if you're a fan of any specific webassembly language, whether it's a you know a general uh purpose, language like python or like um a new language like rain or zig, please write us and we might work together on sdk for near.

A

uh There are various uh virtual machines that we are using uh to run web assembly program set near so right now we are using a wasmer and single pass and vasem time and light beam. So these are both non-optimizing um back-ends for web assembly compilation. There are reasons why we don't want to use optimizing. Compilers uh first of all, is that optimizing compilers like lvm and crane lift.

A

They are they're quite large in their code base size, and we want to be very confident with the webassembly back end that we integrate in into our blockchain client, and so we just try to stay away from them for now, but also optimizing compilers. They have much more complex behavior um they prone to compiler bombs, sometimes, and we just don't want to deal with it yet so we we still use, we use wasmer and single, pass and vasem time plus light beam right now.

A

So right now we're using wasmer 0.17 as as our default execution environment, but we are slowly migrating to osmo. 2.0 osmo 2.0 has a faster compilation, uh time of loading, the module into memory and faster execution of webassembly code in general, so we're gonna have at least twice faster contracts. Once we migrate to osmore 2.0, we've just been extra careful with fixing all safety issues uh in wasmer 2.0 before migrating to it.

A

We also have awesome time and light beam, integrated and engineer blockchain. We don't use it by default. However, any validator can switch to using wasm time plus slide beam if they want to um and the reason we have it. There is just in case. You know we find any kind of bug in wasmer and single pass.

A

We will be able to signal to our leaders to switch to azam time plus light beam while we're fixing this bug, but this hasn't happened yet uh surprisingly, even though wasmer and single pass and bosom time plus light beam, have very different code bases, uh entirely different approaches to compilation light beam as a streaming compiler, their performance, at least for wasmer 0.17- is quite similar on most of our benchmarks. So it was a very interesting discovery.

A

We are also looking into the interpreters, so parity has been used in wasmi uh since the beginning. There is also wasn't free and very um popular interpreter right now we might be looking into using them, because the advantage of the interpreter is that they have a very a simple warm-up, unlike the compilers that need. You know, a complex module loading um before you can start executing the smart contracts.

A

Interpreters are really easy to start up, even though they're much slower when you actually execute twasm code, so we might add them in the future and allow people to choose which, which was a virtual machine to use when executing the smart contract. So they might be able to use interpreters for really really tiny contracts and pay even smaller fees, for them.

A

uh We're also going to be looking into the optimizing compilers too. uh So we we talked to um crane, lift core developers and it seems like there is a way to run crane, lift in an optimizing way, get rid of some optimization stages. I need to make it also smaller in code size that might allow us to have crane lift as as another as another web assembly back-end for webassembly execution at near.

A

The interesting thing is that running sharded proof of stake blockchain actually has strong advantages, um so one of them is that we have an inherent incentive for validators to run multiple virtual machines. So right now you know that uh some virtual machines uh they have implementations of their protocols back in different languages.

A

But what frequently happens is players? Do not really have incentive to diversify the clients that they're, using and frequently the network just converges to one client, because which is you know the cheapest or the faster? So whatever has better configuration parameters which undermines the whole point of having multiple implementations, because um you know if the personability are running the same light client the same client, then you know, if you have coordinated error, it's going to go down anyway with started blockchains.

A

You frequently have a mechanism on slashing that allows you to run shards optimistically, where you kind of put phase into the sharden validators on each chart to produce valid blocks. But then, at the same time you supervise them and if you notice that the blocks are invalid, you slash them.

A

So what has happened on some shared blockchains and what you want to avoid. Is that that when slavishing happens because of some bug which happened hasn't happened to near, we have also haven't enabled sharding yet. But if validators want to really avoid being slashed, because there is a bug in the in the code or because they have messed up the devops um the setup, then they might have an incentive to run multiple clients with different implementations side by side.

A

And if they disagree on the block production, then they would terminate their clients without producing any block. So there is an inherent incentive on the blockchains, with slash into for the players to run multiple clients and uh maybe even the same client, but uh the same client that uses different virtual machines. It can also be an alternative for validators.

A

So there are many uh difficulties with running web assembly: virtual machines on a safety side that we have discovered, so the biggest one is the strict separation of deterministic and ephemeral errors.

A

So what I mean by deterministic versus ephemeral errors is that the deterministic error is the kind of an arrow that has been introduced by the contract developer. Let's say they have written a program that you know, does: division by zero or exceeds the uh the maximum allowed stack sizing in web assembly.

A

uh Non-Deterministic ephemeral error is this the stuff that happens um because there is a fluke I know like you. You run in some other programs on your uh on your uh in cloud instance, and you know, node runs out of memory or you have this corruption, and this is something that can be happening just only on your evaluator machine, or it can be happening on, for instance, on all the little machines that run in the same kernel version.

A

uh This is something that has happened in one hour testnets, and so it's extremely important to be able to separate these errors that are being piped to you by the virtual machine into these two strict categories, because if you make a mistake- and you confuse the deterministic error for ephemeral because of some bug in a virtual machine, then what might happen is that um someone might be able to craft a smart contract that triggers this deterministic error and causes all the nodes.

A

Think that there is an ephemeral arrow and what we do with the femoral errors is that we just shut down the node. We don't want to deal. We don't want to have a special cover mechanism when you have a discorruption uh happening, so we just shut down the note in this case and if we make a mistake and miss categorize domain is the character mural.

A

Then someone can crush the entire network, uh which hopefully doesn't is not possible to happen. If you miscategorize a female error for deterministic error, uh then what might happen is that um some nodes? They might think that they produce a valid block, but it's actually invalid.

A

And if, if this happens on all let's say versions of the same kernel across the subset of the nodes in your network, then you might have a network split or you know a bunch of nose being kicked out, which is also nasty, and you don't want to happen.

A

So it's it's the top of our mind uh to the separate deterministic and ephemeral errors, very precisely for the buzzing virtual machines and occupies a lot of our time. uh Doing it correctly. uh Full compatibility with violism standard will also turn out to be not super trivial, because there are very tiny corner cases um around trap. Handling that we found out are not handled precisely on about the virtual machines, and um this is something we had to. We noticed only post facto uh forward.

A

Compatibility with wasm standard is also important for us, so I'm going to be talking later on how we do the gas, injector and instrumentation vason contracts and uh the new way of doing the gas injector makes a strong assumption that certain parts of osmosis are not going to be extended in the future, and so that's basically an assumption. So forward compatibility wasn't standard that we're going to talk about later.

A

Then you also want to canonicalize the floats. This is something that we do um for all our contracts. Initially, we decided to just sanitize uh our contracts and uh prohibit deploying the contracts on on your blockchain. That uses use the floats, but we very very quickly found out that this leads to a very bad developer experience because, like for us developers, they just want to import libraries um when they develop smart contracts. And, surprisingly, even if you're importing some library that doesn't use flows for like math operations, let's say you're importing some cryptographic library.

A

It still might be the case that you will have some float operations in there because uh of how, for instance, russ does string formatting, you know for for panics, so we decided to allow floats uh in in a near smart contract, but now we can analyze them.

A

And finally, this entangled implementation of other virtual machines from the protocol turn out to be also not super trivial.

A

There are some minor details about how the stack handling is is being done by it was in virtual machines or how how was virtual machines interact with your um uh instrumentation that made some of these details leak into a protocol spec and ties to a specific implementation of the vason virtual machine that we're currently slowly removing.

A

We also had lots of challenges with determinism in virtual machine. Well, first of all, as all of you know here, um the worst case scenario um in in the virtual in the blockchain space is, is basically what determines the the fees? Usually it's not the best case scenario, because if you, if you optimize your fees to target for the best case scenario, then your blockchain is going to be vulnerable, someone might be able to trigger the worst worst case scenario, so um yeah.

A

The the worst case scenario is dictate the fees which did dictate tps on your blockchain. At the end of the day, you can try to special case best case scenario and say, for instance, that if your contract hits doesn't hit some corner cases, then the fees are generally lower.

A

Unfortunately, that leads to bad devex. Well, first of all, your fees might be unpredictable. So uh if developers find out that in certain cases uh the smart contract execution is much more expensive than in other cases based on some. So, like super low level internal mechanism and how webassembly virtual machine functions, then the box is going to be uh pretty bad, but also special case, and best cases will lead to increased complexity of the protocol, which we also want to avoid. We try to keep our protocol pretty simple.

A

We also want the execution time to be similar on similar platforms. We have target hardware at near, but we want people to be able to run our nodes on almost any four core, cpu plus 16 gigabytes of ram machine. uh So we don't want the execution time to vary drastically across different platforms and the finally um big challenge with determinism is: how do you decide? What are your fees- and this is a completely separate topic that I'm gonna get to soon.

A

A

Sorry sorry skipped the slides. um There are performance challenges uh with virtual machines, so one of them is the time to start um it's just the time that it takes for your virtual machine to warm up before it starts uh running the smart contract and uh there are multiple factors that contribute to time to start. One of them is this visualization time, so it doesn't matter what kind of the serializer you use to store your compiled module and there is also the contributing factor of the io cost.

A

So in most cases, you're, probably not going to be storing your compile module in the memory, you're, probably going to be storing it on the disk, as so the the time that it takes to load. It is a big contributing contributor to the execution time on a smart contract.

A

The the loading of the module is also depends on many many variables in your virtual machine um and any smart contract. It depends on the size of the code. It depends on the size of this data section in your wasm.

A

A number of the methods and in wasm surprisingly also frequently contribute to the time it takes to load the module, and obviously a number of the imports also contribute to that uh then uh cold contracts uh is, is a big problem. Someone can deploy a contract and that they never call for many years, and then they try to call it two years later and uh it can be living in a cold storage.

A

So the question is: do we separate cold and hot storage in in a blockchain is a pretty big question uh right now we don't, which means that the fees for the cold contracts dictate the or fees for all all of the contracts, but in the future we might start separating them, because certain contracts are going to be executed all the time like exchanges, and we want them to be cheaper than contracts that execute very rarely and finally, the compilation time.

A

uh The compilation time is is a challenge uh even with single pass and streaming compilers compilation takes slightly different time, and so what we had to do. We had to go all over the wasmer code and remove things like randomly seated hash maps and um like some multi-threading, to make the compilation time consistent. um Yeah.

A

So there are also um safety. Oh wait, one second, my presentation is lagging. I'm sorry for that.

A

Yeah, so, finally, uh how? How do we decide the fees? So this is the big problem for every blockchain, because obviously every operation on a blockchain um should take certain amount of uh money right. You don't want stuff to be executed for free on your blockchain. So how do you decide what costs? What and especially when it comes to the virtual machine that has a very complex internal mechanisms so the way many blockchains address it?

A

They either do the educated guess sometimes, because if they, if you have host functions, which are cryptographic primitives, you might be able to guess how much it should cost, but, most of the time, the way blockchains do. It is by running time-based benchmarks, like they execute operations over and over and over and time them, and determine based on the timing, how much they should cost.

A

So we found out that this is um not as precise as we want it to be very frequently time-based benchmarks, even when the around four days uh produce very high spread of execution time for the same fees and so what we did.

A

uh We we took a big part of our node, uh which is runtime and roxdb, and virtual machine and we're running it on the cpu emulator qmu, and uh I told you we also removed a bunch of the sources of non-determinism, and so now we just count the actual cpu instructions that our node takes to execute those various operations and we were able to achieve precision and represent reproducibility for most of the fees to be within five percent and for a couple of fees that are specifically involved with io. uh It's within 10 15.

A

Precision, which I think is a is a good result.

A

I mean the estimation. Diffuse is still very difficult. Well, first of all, something that we haven't addressed yet is this different cpu operations obviously have different complexity and different execution time. We do treat them the same right now. We ran lots of fusion to make sure we are not abusable in this way that someone cannot really easily construct a contract that abuses certain cpu operation um and also iu operations, are really difficult to benchmark and assign the fees to it's. It's a well known that uh benchmarks for ssds are especially tricky.

A

So we don't even try to write our own ssd benchmark. We use third-party benchmarks to estimate it, and finally, I mean just running things in emulator is extremely slow and we do want to run stuff for many iterations, even inside emulator. For several reasons. One of it is just to reduce the volatility in case we forgot. You know some of them randomly seated hash maps and stuff like that, but another one is to catch the corner cases.

A

So we try to uh generate a wide array of the input and just to make sure we didn't forget some of the corner cases that can have a disproportional uh computation time that our fees are actually deterministic so yeah. It is a tricky then, as I promised I want to talk about. The gas injector.

A

As we know, instrumentation for web assembly is is quite expensive for some for some cases, if you use pivaz motels, which is one of the most popular instrumentation libraries out there, the the cpu instructions caused by the instrumentation code itself can be 90 95 of the cpu instructions of the entire smart contract.

A

So the instrumentation can be dominating the cost of running the smart contract, and this is mostly because the the go-to instrumentation approach right now is to inject host function, call on every uh wasn't block, which is of course expensive, because you're crossing guest and guest host boundary every every wasm block, and so uh what we did here.

A

We looked at uh what wasmer two is doing and what they do is um they inject a global variable uh that they modify without crossing the uh host guest boundary um and they just modified on every wasn't block and they do this injection in the middleware. So uh we took the same approach. We just uh modified pivaz matils in our fork uh to do this kind of instrumentation, so anyone any blockchain that uses wasm, you guys are welcome to use this modify and pivot materials.

A

It allows us to reduce the cost of running wasm smart contracts uh four times according to our most recent benchmarks, and also it doesn't tie you to any specific uh webassembly virtual machine. So that's why we're not using uh wasmers version of the um of this um instrumentation, because we wanted to also work quasim time and other kind of virtual machines, because instrumentation needs to be vm agnostic.

A

Unfortunately, guest injector design does leak into the protocol, spec, not something that we wanted to have, and this is because, when you inject a different amount of assembly code into your webassembly smart contract, uh now your contract might run out of memory earlier or later or like might might hit the stack size limit earlier or later. So it does um kind of leak into the protocol spec, which is quite unfortunate.

A

We haven't figure out what to do with it yet, um and uh but the good news is that you can actually write very suboptimal gas injectors, at least at near. uh We don't uh do gas injection on upon the contract execution. We do it upon the contract deployment and the contract. Compilation and contract deployment is already quite expensive, so you can run a very simple and suboptimal uh gas injection there and not don't don't worry too much about its performance um yeah.

A

So, as I said, uh we have a whole bunch of languages currently four that have as the case either um pending or already been used for quite some time by the community. uh Interestingly, for us, we did have some requests from the community to have std and nostalgic versions of the sdk.

A

Most of the time, a community actually wants to use std version of rast sdk because they do want to import lots of rust libraries and not all of the rust libraries support as the no std mode, and so we had to really optimize an std version of rust sdk and there are also alternative libraries written by the community that you can use the cool thing about um languages that do not have manual manner.

A

Memory management like assembly, script and grain is that you can actually just turn off the garbage collection, because the contracts, as I said, are short-lived and we can totally afford allowing them using many megabytes of memory if they need to without delocating it. So that's an upside of using languages like that.

A

And actually, we haven't made our mind whether we're gonna support a garbage collection on a protocol level. Yet because I mean garbage collection is coming to the web assembly spec. So we have an opportunity to support a garbage collection on a particle level, but we haven't made our mind yet about it.

A

We had to do lots of sdk site optimizations, because people writing contracts are near. They want their contracts to be smaller in size, because that means the fees are going to be smaller for compiling such contracts or for executing such contracts.

A

Technically, it is possible to run extremely tiny contracts on near if you use rust, you know if you, if you do not use std and if you use all the best guidelines for writing tiny code, you can, you can actually have less than one kilobyte contracts when once they compile to assembly, but your developer experience will suffer greatly so most of the projects, even projects that care a lot about the performance and about the size.

A

They actually still use our um as the case with std, so the main contributors to the size actually for these contracts turn out to be obviously strings errors, and you also got to be very careful with std, because it has different code for x86 and wasm.

A

So you want to sometimes dive into the sdd implementation and make sure that when you compile to webassembly you're compiling um exactly what you want to compile, because it can be completely different code and the other interesting thing is that we don't actually use all of these cool tools that web assembly ecosystem has for optimizing. The uh web assembly, like wasm, opt and vasm snip, and mostly because we don't want our developers to shoot themselves in the foot.

A

Wasn't snipped is a very aggressive tool and someone can accidentally over do optim contract, optimization and just cut too many things. So we just don't advise our users on using it yeah.

A

um There are interesting things to be said about using vasem tailored languages like assembly, description, green. They have pros and cons, so pros, obviously, is that they made to be efficient when compiled webassembly.

A

As I said, like assembly script, even has a self hosted. Compiler, like you can compile assembly script with a single script, which is amazing and and grain was designed specifically to be efficient when compiling to webassembly.

A

um So it means you can write in some cases highly optimized contracts with with assembly script in green. The disadvantages, of course of these languages is that they have, they still have small community.

A

That means you have very few libraries, and it's still the case that uh when you want to write a smart contract in assembly script, you need to import assembly script. Library like you, can not at least not on near. You cannot import a library written in another language in compiled webassembly. Yet we haven't enabled this um a possibility yet and also they haven't been battle proven.

A

Unlike rust, you know that large companies like google and mozilla are using for their uh browser development uh assembly, script and grain haven't been battle proven, so we just don't advise uh our defy projects on using them. Yet.

A

The other interesting thing is that we learned quite a bit from ethereum experience with assembly. We like the idea of the execution environments in ethereum, and while we don't exactly have execution environment, we have several layers of virtualization.

A

People can run solidity contracts on near because our evm, which is sputnik vm, is just a assembly smart contract that runs on top of our web assembly virtual machine, and so people can already run up to 4 million gas contracts on inside our evm and very soon this number is going to increase by several x, maybe form x.

A

That will allow you to run pretty much any transaction that you can run on ethereum on near without any constraints, and we haven't even uh piped the host functions from the all of the host functions from the evm into into our host function. So many of the host functions inside the edm are actually run in web assembly, um which makes it quite suboptimal, but it still works and uh obviously like rust, assembly script and grain and zig they're all executed as the first class citizens, without extra layers of virtualization directly on our wasm virtual machine.

A

Finally, I wanted to tell you how we're planning to um test these contracts, so we do have already um quite a few tests and frameworks that peop that various projects used to test web assembly contracts on nir. But we, we came up with this cool idea of having a unifying unified testing approach to any kind of contracts that people are deploying on your blockchain, and this is achieved by basically test and web assembly uh uh web assembly contracts like there were live contracts, so you would take.

A

You would take a test test and you would compile it together with the contract in such a way that the tests themselves are basically your contract cost functions. Then you would deploy this stuff to uh to your node and then you would interact with with tests as if there was contract functions which allow you to unify lots of the experience around the run and the contra code and make your testing experience as close to production to production as possible. So your code and test is going to be highly reproducible in a production too.

A

um So that was it. uh That was not a very long presentation, but if you have any kind of interest in wasm languages, if you like, not just grain and zig, but there are other languages that you like and you want um and you want them uh and you want to build an sdk for them or you like some web assembly, virtual machine, a compiler, please write us and we might give you a grant to work on it. So thanks everyone, any questions in the chat.