 So I'm going to be talking about Dapp Hub. What is Dapp Hub? Dapp Hub is a self-organizing network of logicians, researchers, designers, and developers who have come together to think rigorously about Dapps from first principles. You could say that we are trying to solve the root problems that need to be solved before any interesting Dapps can be created. You're very inspired by the Unix design philosophy. To sum it up simply, the Unix design philosophy encourages developers to write programs that do one thing and do it well and to write programs that work together. This philosophy underpins all of the Unix operating system, and it essentially is a philosophy of modularity, creating small components, laser focusing on them until they are right, and then assembling them together and composing them to higher order systems. These are not new ideas. What I'm talking about right now is a proven approach to design. And particularly, it is something that we think it is a design philosophy that we think is underappreciated in the world of blockchains, both on and off chain. We are also inspired by the free software movement. We think that the free software movement is the most important cultural predecessor to the modern day renaissance in decentralized technology. And because of this, when we look out in the world and we see interesting Dapps that unfortunately use have useless tokens that have been added, we consider it a call to action. We don't like useless tokens, and we like free Dapps. And at Dapp Hub, we are committed to freeing Dapps from useless tokens. Yeah. I knew that'd be popular. Today, when people talk to the proprietors of these useless tokens, they say, aren't you worried somebody's going to fork your project and remove the useless token? It is my hope that in the future, they will ask, aren't you worried that Dapp Hub is going to fork your project and remove the useless token? This is a moral issue. It's something that we feel strongly about. So you mark my words. We are here on this earth to do this. We are here to free the Dapps. We believe in free software. In line with the goals of the free software movement, we have created an ergonomic Ethereum tool chain to empower hackers everywhere. We originally created it for our own purposes, particularly during the development of MakerDial, a stablecoin project that I'm going to be talking about tomorrow, which you should tune into. But we share these tools using the Nix package manager. Now, unfortunately, yeah, give it up for the Nix package manager. For those of you who don't know, unfortunately, I don't have any time to talk about it. But I will tease it with this. Society is just beginning to feel the effects of immutable hash-based data structures, from Git to blockchains to IPFS. It is clear that this method of organizing data is having profound effects on the way that we think about computers and applications. Nix OS and the Nix package manager is what happens when you combine Linux with immutable hash-based data structures. And I will leave it at that. So onto the tools. What do we distribute? The first one is called SETH. SETH is the Ethereum Swiss Army Knife. It helps you use the Ethereum API. If you've ever used the Ethereum API, you know that it's a bit of a pain. It's got curl. It's got post. You have to memorize all these RPC methods. It's annoying. Using SETH makes it delightful. If I wanted to send a function call to a smart contract using the Ethereum RPC right now, it would be curl blah, blah, blah, dash x, blah, blah, blah, encoding, blah, blah, blah. It's horrible. With SETH, it's SETH. Send, address, function name, parameters, boom. You're off to the races. It's that simple. It reads like prose. It's delightful. If you want to read from the blockchain, it's SETH, TX, hash, boom. And it's out there. You can output it as plain text. You can output it as JSON. You can filter by field. These tools, they work together. You can compose this into a more interesting tool on top. The next tools I'm going to describe build on top of SETH. At MakerDot, we build our entire feed infrastructure on top of SETH. If you're doing anything interesting on the blockchain that's reading information from the blockchain and using it on the command line, I guarantee SETH will make your life easier. I encourage you to look into it. If you want to get logs from a contract, SETH, logs, address, there they are. If you want it to stay alive and report logs as they come in, dash dash follow. You can compose SETH commands. Here we have SETH, send, address, value, a subshell, and a nice little conversion function. Is it annoying going from east to way sometimes? The next tool is called DAP. DAP is our developer multi-tool. It helps us use Solidity and it helps us develop DAPs. DAP build invokes the Solidity compiler, the C++ compiler, which is very fast. It's possible you're not used to using it and you'll be shocked by how fast it is. It's much faster than the JavaScript compiler. And if you're in a hurry to make your DAP, you really want to invoke the C++ Solidity compiler. It has testing. It has a native Solidity unit test runner. You don't want to switch to some other programming language to write your tests. You want to keep that context on Solidity. You can write your tests in Solidity and it has stack traces. Isn't that nice? Never had stack traces before in Solidity. So it makes debugging much, much easier and it runs your tests really fast. I'm talking 150 tests in under a second. Easy. And the reason that it runs them so fast is because it has its own, oh no, I'm sorry, before I talk about that, has DAP create. DAP create, similar sort of, trying to make using the Ethereum API a little bit more prosaic. We've got, if you want to deploy a DAP, do the blockchain, it's DAP create, type name, parameters, boom. You can see it's using Seth in the background there. Like I said, these tools, they build on top of each other. This is the UNIX design philosophy in action, people. It's a very, very nice way to build on top of your previous achievements by making things modular. Like I was saying, the reason that DAP runs its tests so fast is because it uses something called HEVM under the hood, which is a Haskell EVM execution environment. We created HEVM for a few different reasons, mainly around verification. We're going to link it up to other interesting Haskell verification tools like QuickCheck. But what I'm showing you here is that it has an interactive solidity debugger. If you want to step through solidity functions on the command line, you can do so with DAP using HEVM under the hood. Up top, you can see all of the instructions as they get executed. Super cool, super interesting. And last is Dapsys. I'm going to spend the rest of my time talking about Dapsys. This is our provable standard library of smart contract building blocks. A ton of useful stuff here. And the reason I say it's provable is because it was built with an eye towards formal verification. It is the truth that not all contracts are equally provable. You have to build with the expectation that it will be verified in the future. And that is what we've done with Dapsys. A lot of it is going to sound familiar to what I've been saying so far. You have to make them really, really small, easily isolatable so that you can check their invariance and then it can slot into a larger system, the UNIX design philosophy. This is a proven approach to design, I told you. This appears here in Dapsys. There's a ton of useful building blocks here. I could honestly have a whole talk about each one of these. I'm going to talk about two today. But first, let's talk about Dapsys at a high level. At a high level, there are two main types of Dapsys packages. Boxes and mixins. Mixins will appear very familiar to you. These are base classes. You mix them in to your DAP logic to get access to interesting functions and modifiers. Here, my DAP is mixing in dsauth and dsmath. dsauth is providing access to this auth modifier and dsmath is providing access to this wmull function. I don't have any time to talk about dsmath, but what I can tell you is that this is a very interesting safe math library, probably the most interesting safe math library in the business. It does not just do overflow protection. It does interesting types of token mathematics and that's what wmull is doing there. The second high level idea are boxes. This is a concept that we've invented to describe safe prefabricated components that you take directly off the shelf and put onto the blockchain without modifying them. You think of them as boxes. Again, I'm reusing metaphors here, but what we're doing is we're taking components, we're putting them on the blockchain, taking more components and then we're wiring them up. It actually looks a lot like hardware design, prefabricated components and wiring them up into DAPs. That's what we've got here on the slide. We've got a bunch of boxes that have been wired up into an interesting DAP. Most of MakerDAO is made up of boxes that have been wired together. There's actually relatively little custom code when you look at the whole thing. You don't need to write that much and you don't need to change the code. You don't need to inherit from it and add in your own logic. You just take it off the shelf, put it right onto the blockchain. So let's talk about a mix-in and then let's talk about a box that it enables. This right here is the DS-Auth mix-in. If you don't take anything else away from this talk, please consider using DS-Auth. So that means wake up in the back if you're not paying attention. This is the only thing that is truly important in this entire talk. DS-Auth is a mix-in that allows you to abstract your authorization logic away from your DAP's business logic. What I mean by that is that your DAP can just focus on whatever it was created to do and it doesn't need to think about who is allowed to call it, why, when or how. And the way that it does this is by providing a DS authority object, all DS-Auth types provide a DS authority member. DS authority is an interface, just like ERC-20 is an interface. It's a function that different boxes are expected to implement and that function is can call. Can call will respond true or false if the source can call the function on the destination. So here we've got Bob calling the finalized function on the auction and the auction asks its DS authority box if Bob can call the finalized function on the auction. And the DS authority will respond true or false based on any arbitrary business logic and this is what makes it interesting and this is what makes it important because that business logic could be as simple or complex as you want. Look at all this business logic. The DS authority could be a simple whitelist. Bob can call finalized. It could be a time-locked whitelist. Bob can call finalized in two days. It could be a role-based permissioning system. We have one of those in Dapsys. Bob is a member of group one which can call finalized. Or, and this is where it gets interesting, Bob can call finalized in two days unless the token holders veto him. What I'm saying here is that DS authority moves the conversation forward on governance. This is blockchain governance right here. This is what you're looking at. Your Daps are your Daps and your governance is your governance and your governance is the DS authority interface. If the entire community converges on can call, that's it, just can call, I promise you 2017 will have been a good year for blockchain governance. This is a germane idea. This is a new idea. And if we can think in this way, abstracting authorization away from governance, we will move significantly beyond the only owner modifier and we can start using the auth modifier. This is a big deal. And I'm gonna show you, yeah, thank you. This is a big deal. This is blockchain governance right here, DS auth. Write that down. And I'm gonna show you now a box that is enabled by DS auth. That is the DS token box. DS token, as you can imagine, is a token. It's an ERC 20. And it is of type DS auth. And the reason that it is of type DS auth is because it has four new functions. Stop, which stops token transfers. Start, which restarts token transfers. Mint, which creates new tokens for the caller. And burn, which removes the caller's tokens, lowering total supply. We have thought about tokens for a long time at Dapp Hub. We're one of the most senior teams in all of Ethereum. We've thought about tokens basically as long as Ethereum has existed. And we have decided, based on our love of the UNIX design philosophy and our own needs in MakerDAO, that this covers the entirety of the token use case. Because what I'm saying here, what I'm up here on stage to say is let tokens just be tokens. Just have them be tokens. They're just a database of token balances. They can only do a few things. And here we can see this diagram that they can still be interesting parts of Dapps, right? We've got Bob here calling his claim reward function. The distributor is authorized to mint tokens and distribute them to Bob, right? We've got fancy things. We've got fancy business logic. It's just not in the token contract. And when you make a token contract, only a token contract, but you still make it flexible with DSR and these extended functionality, you can have interesting things. You can think about tokens in better ways. Let me show you an old way that we used to think about tokens. We used to think about tokens kind of in this front end controller data store model. This is a very common model to think about tokens. It was called the upgradable token. So what you had was you had your static front end, you had your static token data store, and then you had your controller, which had some sort of token business logic, whatever your token did. In this case, it's doing voting. And then you would call the controller and sometimes you'd swap it out when you wanted to update the functionality. The hope is that you wouldn't swap out the data store, but you can't merely make that promise when you're looking at something like this, right? You can't provably make that promise when you have everything quite so dynamic, right? We wanna make credible promises to our stakeholders, provable promises to our stakeholders. And not only that, this is too complicated. This thing is huge, it weighs gas, and it's not being a token, it's being a bunch of stuff. It's difficult to reason about. Let's look at voting in a much easier way, the box mentality. Here we have Bob calling vote on the voting box, and it's just pulling tokens. It's just pulling tokens into its box and holding them is literally like a ballot box. I mean, look at this thing. It pulls the tokens, it counts the votes. When everybody's done voting, it releases the tokens. Much, much better way to vote. The token is the token, the voting box is the voting box, and look, the voting box can be an authority, right? This is what I'm talking about when I talk about token governance. It can be a DS authority for an entire system of dApps. And not only that, it can be a DS authority for the token. You can make a cycle here, where the token holders are governing the authority that controls the mint, burn, start and stop functions on themselves. It's like a cycle because they're governing their own token. That's neat, that's cool. That pushes the conversation about token governance forward. And that's what we do at DAPT Pub. If you're interested in this type of stuff, if you're interested in formal verification, if you're interested in that old school hacker mentality and aesthetic, I recommend that you come and introduce yourself. Come to DAPT Pub.com, all the links are there. Check out our tools, check out our chat, DAPT Pub.Chat. We've got a lot of interesting stuff. We are here to create free software for DAPTubs. Thank you.