Dapple Dev Workflow - Nikolai Mushegian

alright great my name is Nikolai I'm here representing Nexus developments where a athyrium R&D shop and consultancy and among other things we publish open source software to help other developers what I'm going to focus on today is called dapple so it is Apple dabble is a developer tool for people targeting the etherium 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 DAP file and it's a 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 like you do some really interesting things and in particular the entire like development workflow of creating contract systems that talk to other contract systems kids really a it helps a lot to how these features so let me just go through you should use again the first thing is that the key insight that drives this first innovation is that if theory em land is slightly different from most of the other you know programming language environment worlds because in a theory i mean 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 it like an instance or like a deployed code object so this would be like if you hard code like a web endpoints into your JavaScript package or something that's considered bad practice you want it like separately how to depend on a configuration where there you configure your endpoints and then have all that logic in your code but in a theory immunes 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 an absolutely no reason to redeploy everyone should be treating it sort of like a library like you know you have the math library on a theorem 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 erc 20 token but that hasn't address in it that's part of the definition of that code packages that there's an object deployed so yeah so this is an example job file don't worry about it too much the key thing is this highlighted thing which is that the 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 chained forking you'll notice it's a user experience very similar to get that because they're very similar data structures the missing part here is merged because there's no analogue to resolving merge conflicts automatically when you try to replay Center 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 athyrium chain without their permission basically just because of how the data structure works but by default we let you specify remote one and internal just means a brand new blankie vm on your machine and for QVC and where it should be self-explanatory and finally EVM extensions are when you slightly change the behavior of the virtual machine on your private chain and this lets you do some really interesting things as you'll see so now let's go through the workflow how have we developed apps using double first thing find some dependencies this is like a habit that you have in every other language for some reason everyone wants to start from scratch from there creating their own contracts this is our as a hint so we suggest that we have like something like sort of like a standard library which we are keen to get formally verified and it has a lot of stuff like Roxy actors tokens by the way you can read the list I'm sure the other ideas that these are like composable building blocks each is very simple and easy to verify and then you actually most apps can be built out of just a collection things like very few like each DAP that 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 this I mean these again it's very simple contracts but they are in production systems right now in multiple systems like nothing in here is something that hasn't been used so the next step is building and linking which is boring but it's worth noting that solidity has no name spaces 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 abscess versions and being able to reproduce and compile without having like type name collisions requires us to have a custom linker so we're going to maintain that until 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 in 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 a chain for key so this this is an example test if you use any unit testing framework another in other languages this should be familiar setup gets called every time and then if you have multiple test functions they each get called an isolation so our first example of a using chain forking this is a suppose we did Apple chain new and use and we specified the internal vm which means like a brand-new fresh EVM then we deploy our contract to it call setup and then concurrently we can fork it and then run each test independently so that's nice but we really wanted so like part of the value of dapple is that we can take these dependence systems and make a very accurate mock of them and we preserve all the type of information you can be very certain that the behavior will be similar on the live chain and on your fake local chain but 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 a 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 Morton context this will work but if you run this on a private internal this won't work because you know unless you burn some ether first so I should have like written the usage behind this but basically what happens is first you enter the answer the Morton context and then you do dapple test on this contract and the result is that it works this address zero refers to address your own morden and so when you assert that the burned balance is more than zero it's true all right 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 it's harness has hijacked that creates and call off codes and makes instead what usually when you have payer call it creates a message costs like internal to one transaction but instead what we do is actually create a full transaction and then block the wall outside EVM execution until it gets confirmed you combine this with the chain forking feature what you can do is simulate live deployments before you actually do them do dry runs and then you can run consistency checks on the results of your system like make sure that you're up the update that you want to do it doesn't screw anything up so here's a real world example of like we want we might want to do this you're on slack and you get a message for me that says hey please confirm proposal 66 it is a critical bug fix it's going to swap out some of the contracts this ones that have don't have this book so if you're a responsible administer of multi sig folder of whatever system you're running you will of course do a mock chain fork and run this transaction a simulated 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 this type information preserving this type of information in the default 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 of immunities to make sure that this you know 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 confirmed puncturing blah blah blah and so in this case what we're doing is we're confirming it's from our address but then we're fit tending to set the origin to a different address which is one of the magic features of the script contract so that the origin is mocked then we do a confirmation from that origin and then we show in this example to confirm also does the trigger so the update runs and then we do a consistency check and in this example you can see our maid of 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 all right and then the final step is publish your job file yet other people to import your code and have some code reuse because there's so much duplication of effort going on in the ecosystem right now is partially because it's just so hard to reuse other people's code so I'm going to very quickly give very small sneak peak about what are some other things that are coming basically all the things I described could be done in a GUI so you could you know do your own the Dow hack through a through a clicky you I if you want to let's and then some more things that we have in the pipeline a better more wallets I DVM extension features so one thing is uh having one of the addresses be like a hard-coded contract which is a thin client and so this is call i call it DIY sharding basically if you have to private chains you can make up your own interpret and communication scheme very easily if you have the thin clients for the other chain as a like EDM 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 side chain that say does SMS relay like this is the example we have right so it does this it does SMS n but it might inside this function and it emits 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 use it and so this is the general direction we're moving towards and so that's actually only to talk about thank you for listening let's go to lunch