 I want to talk about the challenges that we face when we're building a virtual machine for a blockchain, we want to run smart contracts, a lot of you know, we want to have a bunch of contract security tools, we want to be able to audit them, we want to do some static checking, model checking for verification and testing and so on. Usually, these are built as separate tools and we also want to have like clear consensus of what we're building, what is the exact behavior of this virtual machine, so we want to have like a trusted runtime, we want to have good documentation so implementers know what they're building, we want it to be perfectly unambiguous, we just want to make sure we can avoid consensus bugs. And again, these are all things that people tend to work on separately, someone's writing an documentation, someone's formalizing the EVM, the yellow paper as well. So, I want to pitch another approach, which is what we apply in the K-framework, which is this idea that you can kill M-darts with K-stones. Basically, the idea is that you specify your language once and you derive the tools that might sound like magic but it's sort of what you're doing with a parser, you're not saying that to write a parser you see most of the time, you're probably writing a grammar and a tool that's going to generate a parser for you. We take that same approach with languages to the next level where you specify your language in formalism, mathematically, you can get it as math, you can get it as programming, and from there we can generate parsers, interpreters, program verifiers, we're working on a bunch of tools like model checkers and so on. But the idea is you specify your language once and then you get all the tools. I'd argue that it's ambitious, let's derive all the tools from one specification, but it's also realistic, runtime verification is doing this and we've been doing it for quite a few years, I'd say it's pretty successful with it. So it's not paper work, it's ambitious but it's realistic. So one example you might have heard of is the KVM, it's a formal specification of the EVM in the K-framework. So it's formal like the yellow paper, it's not the exact same formalism but it's still executable so if you could actually execute the yellow paper so you can run it as a node basically. And it reads like code with a lot of documentation because we've opted for a literature programming style where you have a bunch of documentation and then we'll look for a list. A lot of nice tools we generate from this is a tool we work on called Firefly, which is sort of a truffle integration to build a bunch of dev tools by the truffle. We generate docs like the jello paper as some, I'd argue, easier formal specification to read than the yellow paper. We do verification to a bunch of verified smart contracts and we're building more cool stuff all the time. And I work on K-Walsons, which is just a formal specification of WebAssembly in the K-framework. Right now it's mostly a spec of pure WebAssembly, very similar to the official spec, which is nice because they chose the same formalism as we've been using for a while so it's a testament to it's a good formalism. So we're rewriting logic or rewriting bits. It's these two added beddings. We have a prototype embedding for eWalsons, even though that's not on the final state, we're building prototypes. We're working with Polkadot and Substrate to ramp up our verification abilities to do formal verification on WebAssembly. And because K is a Walson, most EDM tools, the KDM tools will become eWalson tools when we take some massaging. But the idea is like we're doing Walson now and when eWalson kicks in, we're ready to go. And if it doesn't kick in, we're ready to do any other WebAssembly work. And that's what we're doing in Substrate. Here's the slide you want to photograph if you want to stay up to date on this talk to me after.