 All right. Great. My name is Nikolai. I'm here representing Nexus Development. We're an Ethereum R&D shop and consultancy. And among other things, we publish open source software to help other developers. The one I'm going to focus on today is called DAPL. So it is DAPL. DAPL is a developer tool for people targeting the Ethereum virtual machine. It's a collection of utilities that are mostly loosely coupled, but they all center around a common data model which is one of our major key innovations, from my point of view. So I'll go through all these real quick and then I'll go into a little more detail. The main thing is this shared data model which we call the DAPL file. And it's basically a descriptor for both code packages and also deployed systems. And then chain forking, creating local chain forks, and then having modified EVM behavior on those local chain forks. These three things together allow you to do some really interesting things. And in particular, the entire like development workflow of creating contract systems that talk to other contract systems because really it helps a lot to have these features. So let me just go through these again. The first thing is that the key insight that drives this first innovation is that Ethereum land is slightly different from most of the other programming language environments because in Ethereum, we actually all share a global runtime environment. And so this blurs the line between something that's a code package and something that's like an instance or like a deployed code object. So this would be like, if you hard code like a web endpoint into your JavaScript package or something, that's considered bad practice. You want to like separately have it depend on a configuration where there you configure your endpoints and then have all the logic in your code. But in Ethereum, you have things like, say, the Ether token wrapper which is stateful. It's a deployed object that you interact with. But it's also not... There's absolutely no reason to redeploy it. Everyone should be treating it sort of like a library. Like, you know, you have the math library on Ethereum. Everyone uses the same address or in theory we should be doing that for the math functions. Likewise, we should all be using the same package for like the Ether token wrapper which creates it into an ERC20 token. But that has an address in it. That's part of the definition of that code package is that there's an object deployed. So, yeah. So this is an example .file. Don't worry about it too much. The key thing is this highlighted thing which is that the type information is very rich. It has all the metadata we need to just fully recreate how this thing got here. So the next innovation is chain forking. You'll notice it's a user experience very similar to Git. That's because they're very similar data structures. The missing part here is merge because there's no analog to resolving merge conflicts automatically when you try to replay a set of transactions and it doesn't have the same result. So that's chain forking. And finally, okay, this is an example of basically you can actually fork any public Ethereum chain without their permission basically just because of how the data structure works. But by default, we let you specify remote one. Internal just means a brand new blank EVM on your machine and fork. EZC and Morton should be self-explanatory. And finally, EVM extensions are when you slightly change the behavior of the virtual machine into a private chain. And this lets you do some really interesting things as you'll see. So now let's go through the workflow how we developed apps using DAPL. First thing, find some dependencies. This is like a habit that you have in every other language but for some reason everyone wants to start from scratch when they're creating their own contracts. This is our, as a hint, we suggest that we have like something like sort of like a standard library which we are keen to get formally verified. It has a lot of stuff like proxy actors, I'm sure, yeah, the idea is that these are like composable building blocks. Each is very simple and easy to verify. And then you actually, most DAPs can be built out of just a collection of things. Like very few, like each DAP, each new system that we make usually only has like one or two contracts with custom logic. And then it has like five dependent contracts that are just things we've built before. So again, yeah, if you're interested in formal verification, this is a, I mean, these, again, these are all contracts, but they are in production systems right now in multiple systems. Like nothing in here is something that hasn't been reused. So, yeah, the next step is building and linking which is boring, but it's worth noting that Solidity has no namespaces and this is kind of a smell that our contract systems haven't really gotten that complicated yet. Maker Core, for example, has four different deployed DAPS versions and being able to reproduce and compile without having like type name collisions requires us to have a custom linker. So Solidity gets namespaces. So after you've written some contracts and you've built them, you obviously want to test them. And our perspective on this is that the primary consumer of contracts is other contracts. And so we emphasize writing your test of Solidity, pretending your other contracts and communicating with it. And for this we have a magic test contract where it has an associated harness that understands how to interpret the functions defined on it. So this is our first example of chain forking. So this is an example test. If you've used any unit testing in other languages, this should be familiar. Setup gets called every time. And then if you have multiple test functions, they each get called in isolation. So our first example of using chain forkings, this is suppose we did a DAPL chain new and we specified the internal VM with a brand new fresh EVM. Then we deploy our contract to it, call setup, and then concurrently we can fork it and run each test independently. So that's nice. But we really want to so like part of the value of DAPL is that we can take these dependent systems and make a very accurate mock of them and we preserve all the type information. You can be very certain that the behavior will be similar on the live chain and on your fake local chain. You might as well just use the real thing. I mean, it's even better. So in this example, basically you write a test and you assume that the contract is running in the context of like an existing chain but you can do more stuff with it in your private context that lets you test a few more features. So to give a concrete example of this, if you run this in the more than context, this will work, but if you run this on the external chain, this won't work unless you burn some ether first. So I should have written the usage behind this but basically what happens is first you enter the more in context and then you do DAPL test on this contract and the result is that it works. This address zero refers to address zero on more in and so when you assert that the burned balance is more than zero, it's true. So testing is kind of interesting but it gets really interesting when we want to deploy contracts which is one of the applications of what we called wallet-side scripting, which is another magic EVM contract but its harness has hijacked the create and call op codes and makes what usually when you have create a call it creates a message call like internal to one transaction but instead what we do is actually create a full transaction and then block the wallet-side EVM execution until it gets confirmed. And you combine this with the chain forking feature where you can do is simulate live deployments before you actually do them, do dry runs and then you can run consistency checks on the result of your system like make sure that the update that you want to do doesn't screw anything up. So here's a real-world example of we might want to do this. You're on Slack and you get a message from me that says hey please confirm proposal 66 it is a critical bug fix, it's going to swap out some of the contracts with ones that don't have this bug. So if you're a responsible administrative multi-sig holder of whatever system you're running you will of course do a mock chain fork and run this transaction and simulate environment to make sure that it still passes whatever consistency checks you guys have defined. In our case let me show you the example. So this is why this type information preserving this type information in the DAF is so powerful is that then we can hoist it into the wallet-side scripting environment and have the full type system there with all the type information you need to make sure that this what you're doing makes sense. There's actually a token defined in the environment, it's actually typed as a token, it has a confirm function blah blah blah. In this case what we're doing is we're confirming it from our address but then we're pretending to set the origin to a different address which is one of the magic features of the script contract so that the origin is blocked. Then we do a confirmation from that origin and then we, so in this example the confirm also does the trigger so the update runs and then we do a consistency check and in this example you can see our made up consistency check failed so you know that this wasn't actually me, this was some hacker that is trying to run a bad update on the system but each multi-sig member can easily independently verify what the resulting state of actually running those transactions are. And then the final step is publish your .file, get other people to import your code and have some code reused because there's so much duplication of effort going on in the ecosystem right now and it's partially because it's just so hard to reuse other people's code. So I'm going to very quickly give a very small sneak peek about some other things that are coming, basically all the things I described could be done in a GUI so you could do your own the DAO hack through a clicky UI if you want to let's see. And then some more things that we have in the pipeline are better more wallet-side EVM extension features so one thing is having one of the addresses be like a hard-coded contract which is a thin client and so this is called I call it DIY sharding basically if you have two private chains you can make up your own inter-blockchain communication scheme very easily if you have the thin clients for the other chain as a EVM extension or like a hard-coded contract likewise creating like a mint opcode would allow you to write your private chains consensus mechanism in the EVM and finally system calls allow you to bridge the old world web with the new world, you know, thin proofs for everything and you can have like a dedicated sidechain that say does SMS relay like this is the example we have right so it does this but it might inside this function and it meets an event and this is like a proof that this company claimed that they sent an SMS at this time in response to some action that you did and so this is, you know, the general direction we're moving towards and so that's actually all I have to talk about thank you for listening let's go to lunch