 quickly, because I keep forgetting to do this, introducing myself. I am not a professional MC. I am actually the Executive Director of the Ethereum Foundation. My name is Ming Chan. And I take great pleasure in actually performing the duties of MC every year, since Stephan won. So very happy to see everyone here. And now I introduce Hudson Jamison. Thank you. Good morning, everybody. All right. All right. So I'm Hudson Jamison. I work on a startup called Oaken Innovations and also work for the Ethereum Foundation part-time. Quick about me just for a few seconds. Been involved in blockchain since 2011. Worked for a bank called USAA doing their blockchain stuff for a few years. And then eventually worked for the Ethereum Foundation in Oaken, which is what I currently do today. I have one wife total on the top left. And then I also have three cats. Is this for my wife or for my cats? Either way, if you like cats, you would love Vivian, Fry, and Lelu. So that's just a little bit about me. So Solidity is a high-level language for the Ethereum protocol. What I mean by that is, usually when you get down to the low-level parts of programming languages, you have a bytecode. You have assembly and stuff like MIPS, and all this other confusing stuff that people generally don't know how to write. It's not human-readable. So what we've done is the Ethereum Foundation has created Solidity, which is a human-readable language for smart contracts. So if you've been coding in Solidity or been involved in the Ethereum community for a while, this talk might be a little bit boring. So I've decided to add a trivia question. The question is, how many high-level languages does Ethereum have? We're counting defunct languages, but we're not counting things like E-wasm, so you can't say Rust and C and other ones that would compile to E-wasm. So be thinking about that, and we'll get the answer in a few slides. So Solidity looks like JavaScript, but it has types, and the contracts kind of seem like classes. So it's about two years old, maybe a little bit more than that, and it's a very easy language to pick up because it has a lot of the qualities that web developers might be familiar with. The code that is written in Solidity is compiled to the Ethereum virtual machine. Once it's deployed to the Ethereum virtual machine, it's a closed environment that runs on every node on the entire Ethereum network. So you can write a smart contract and deploy it, pay the miners to mine the contract, and when you deploy code, it's deployed across every single node in the Ethereum network, which is really, really cool. The issue with that is you can't have outside sources of information, so you can't have sports scores unless you put them in manually and have to trust the source. So if you wanna get more information on that, look up oracles or trusted data feeds into blockchains. So contracts in Solidity are easy to write, but they're very difficult to make secure. There's a number, I'm just touching on this briefly, because there are many flaws in contracts that have caused a lot of lost funds. It's a very nuanced thing to understand, and there's growing resources for creating secure contracts, but it's not completely there yet. Everyone's doing a really good job trying to come up with best practices and create things in the language to provide security, but we all have to keep up with that, and I encourage you to look at the Solidity documentation under some of, there's a section about security considerations that you all can look up if you're interested. So here's the answer to how many high-level languages Ethereum has. It is six. There's Mutin, which is a C-like language that was deprecated around 2015. Serpent and Viper are Python-like languages. Serpent is deprecated. LLL is either called low-level language or Lisp-like language, depending on who you talk to, and that's one of the lowest-level, high-level languages we have. There's Solidity, and then there's a new one called Bamboo, which is supposed to be very safe, written by Yoichi and some other contributors from the community. If I got this question wrong, please go online and yell at me on Reddit because I love feedback and I love internet trolls, so please tell me if I'm wrong about this one. So contract standards are beginning to emerge. We have ERC-20, which many of you have heard about. It's just a set of standards for having a token on the blockchain that's interoperable with other tokens. There's also smart contract security best practices. I put the URL on the bottom and I'm gonna publish these slides to Twitter so you all can look it up after, but this is from a company called Consensus, and they have this on their GitHub. So I'm gonna walk through a contract from creating it to deploying it to looking in a blockchain explorer about it, just really quick. In order to do this, all the tools that you need to do this are online right now. The Fox logo is for MetaMask, which is an online plugin for your browser. I believe it's in Chrome and Firefox, right, at least it's in Chrome. And what you do is when you have a transaction that you need to push to the Ethereum network, it acts as a bridge between your browser and the Ethereum network. We also have Remix, which is an online, solidity integrated developer environment. What that means is that when you want to write and test code, it provides a lot of debugging features. You can run static analysis on it. You can call functions. It's a really helpful tool for writing contracts. And then finally, we have Etherscan. Etherscan is a blockchain explorer so you can see the contracts you've created and the transactions you processed. So first, let's go to Etherscan. So this is an example of pulling up contract code on Etherscan that's been verified. As you can see, we have the contract source, the amount of Ether that's in the contract and how many transactions have occurred. So let's just dive in and write our first smart contract. So this is a very, very simple contract right here. I'm calling it Simple Store. And the only purpose of this contract is to store an unsigned integer or to retrieve an unsigned integer. So it's very easy to start a contract. You just declare it as a contract. You go in and then you declare your variables at the top like many programming languages suggest you do. And then you can go in and create functions and events. Events are just like log files. So as you're going through and debugging your code on the blockchain, you can have these log files spit out events whenever something happens in your code. So in our case, we have the set function. We made the set function payable so we're able to send Ether to it. That's another important security consideration. In the old days, you would have to have a lot of workarounds in order to prevent your contract from keeping Ether and not letting it be able to be sent out. But now we have this payable modifier that makes it so that functions have to have a payable modifier in order to receive Ether, which makes it a lot safer if you're accidentally sending Ether to contracts. In the set function, I'm calling an event after I've stored the data that says the data that I've stored. And then on the function get, I add something called constant. On a blockchain, you can do a transaction where you pay gas and you pay transaction fees in order to change the state of the blockchain. There's also something called a blockchain read or a constant function. There's now newer grammar, I guess, or newer function keywords around that. I think it's pure and a few other ones, so look that up. But you can still use constant for the time being. What it does is when you have a constant function, you can do a free blockchain read to retrieve your data, which is very powerful because it's just like reading a database. And I don't wanna spend money if I'm just reading a database. So that is the smart contract in a nutshell. What I'm gonna do now is I'm gonna hit the create button that I had on the other screen. And when I create the contract, a MetaMask confirmation box pops up in your browser. Again, you didn't have to download anything. The only thing you had to install was a Chrome plugin and open up a website. So we're opening up this MetaMask box and we're hitting submit. We're putting in a gas price that kind of sets up the transaction fee. And now we go to Etherscan to see our transaction being mined. So it shows that the contract's been creative. It gives the input data, how much the gas fee was, and a bunch of other neat data for you to see. Now we're gonna go to the contract itself before we were just in the transaction that made the contract. Now we're in the contract itself. And Etherscan provides a lot of other really cool tools. So we have transactions where you can see transactions that are happening between the contract and the user or the contract and other contracts. We see if there's any ether in the contract. We can see who created it and we can even go and publish the contract code. So say I have this simple store contract and I want other people to be able to look up my contract and see the code. I can go into Etherscan and publish that code inside of Etherscan in a way where people can read it. So now when I go to contract code, it'll actually show me the code that I wrote and you can look up functions much more easily in Etherscan. It's a really, really powerful tool that's widely used for transparency purposes. So going back here, after that transaction's mined, we have a log, basically a blockchain log under there. And what it does is it shows you that you transacted with the browser, that you had a transaction mined and block 194.6928. And it shows you a bunch of other details, a lot of other interesting things. If you look here, we're gonna go ahead and set a variable. So on the right side of the screen from there before, you can call the set function. So we're gonna set it to 100. So again, we call MetaMasks and the transaction. And now when you read the smart contract on Etherscan, you can see that instead of having a value of x equals zero, we have a value of x equals 100. So we've successfully stored an unsigned integer into a smart contract. We have many integrations inside of Solidity. Remix is one that I mentioned. We also have Visual Studio. We have IntelliJ, Vem, Emacs, Sublime. I think that's Adam. Basically, I went in and if you're using whatever IDE, whatever kind of browser you want, you can go in and plug it into whatever is comfortable for you. And it has a lot of things like syntax highlighting. It has a lot of things like, yeah, syntax highlighting. We have tools like Solgraph and Solidity REPL, Selenium and a Disassembler. And then at the bottom, there's Populus, Embark and Truffle. Those are really cool tools. They're programs you download. They're usually under over MPM, so it's like a Node.js program. And you can write test for your Solidity contracts and things like Mocha. You can also have them automatically compile your contracts and redeploy them on the blockchain. There's just so many cool tools in there. Ethereum package management was a collaborative effort by a number of Ethereum software developers that involved having an MPM-like interface for the Ethereum contracts that are very widely used, such as ERC-20. We also have Solgraph. So contracts talking to other contracts are very, very hard to visualize. So Solgraph takes your contract code and your functions and it tells you all of the inputs and outputs and potential things that can happen within your contract. Solinium is a tool to use, I think it's a linter for Solidity. I don't use it myself, but it's very, very popular on the whole Sublime package manager. Oh man, so that should be saying love Solidity, but it looks like something is unknown less than Solidity and now it's covering up my slides. So you can go to Jamison, no go to hudsonjamison.com slash speaking engagements to see my slides. You can go to Witter at Hudson Jamison or edit usubtacular and you can find all my information on there. I have a couple of minutes. So if anyone wants to yell a question, I'll repeat it back through the microphone and feel free to ask any questions who has one. Raise your hand. I've seen some like beta or alpha versions of Eclipse plugins. It might be further along than that, but I'm kind of unaware if there is a plugin for that or not. Just because it's not on the slide doesn't mean there's not a plugin for your IDE. These are just the ones that I've been able to very quickly find. So it's definitely worth looking up. Good question. And the question was, if I didn't repeat it already, is there something in the Eclipse IDE that works with Solidity? Next question. Yep. What do I think is the biggest problem with Solidity? The biggest problem is that it is a young language and the problem with young languages in general across the board is that they don't have a lot of features that programmers are used to, so that causes a lot of frustration. There's a lot of basic primitives and a lot of things that make it easy to start out, but otherwise there's not a lot of advanced tools. Also the safety of Solidity has been brought into question and a lot of people are like, Solidity's super unsafe. Look at all this money that's been lost, but I mean, this is all a big experiment, guys. Like this is a super new language and if anyone's complaining about Solidity being insecure, they should come up with a way to make it more secure and start getting involved in these discussions and these tools. So that's kind of the approach I take with that. We have time for one more question. Yep. What upcoming feature am I most excited about? So if anyone saw the presentation on Zoecrates yesterday, there are pretty new features to get cryptographic primitives inside of the EVM and therefore Solidity to do ZK Snarks, which are called Zero Knowledge Proofs. Zero Knowledge Proofs enable semi-private and private blockchain transactions and I think it's a really, really powerful thing for the Ethereum ecosystem. I'm Hudson Jamison. Thank you all so much for listening to me. Feel free to visit those websites and I'm gonna have Christian come up after this. Thank you, Hudson. Before I introduce the next speaker, I just wanted to say that today in the breakout hall, there is a Zero Knowledge Proof ZK Snarks breakout session and it starts at 10.40 and ends at 3.20. So you'll be able to learn more in the breakout hall later today. I'd like to now introduce Dr. Christian Reitwiesner and he will be speaking on flexibility and Solidity. Can I have the screen please? I think it's open already. Okay, thanks. When you design a programming language, you have to make compromises constantly. There are people who request features and of course features are nice, but with each new feature, the language gets more complicated and thus either harder to understand and it's easier to make a mistake than more complicated languages. So you have the constant balance between functionality and safety. Of course, there are features that are safe, but yeah, that's the compromise you have to find and this has not been the case for general purpose programming languages for several years now, but in blockchain, there's always the factor of cost. So smart contracts have to be very cheap to execute and that also limits the features you can add in a language. Back in the days when Solidity was started, the initial goal was to create a usable high-level language as fast as possible and I think we succeeded in that, but of course, we made some decisions we now, yeah, which turned out to be not that, turned out not to be the best decisions and now is the time to change them and Solidity is still a language that changes and that allows us to make the necessary changes to the design and yeah, the path you want to go is we want to keep features that are relatively safe and they look like high-level features, but most of them are actually quite low-level, so we want to have features that look like high-level features but are still cheap and we want to remove everything that can surprise users or has some magic involved and then a third factor is we are adding formal verification tools that are easy to use and I would like to stress this easy to use part because that is essential and we will see that later in the talk and then if that is not enough for you, we provide direct way to access very, very low-level features of the Ethereum Virtual Machine and the important point is here that we remove everything that is kind of intermediate level so for example, address.call will be removed in the future because it has some magic, some unexpected things involved that we would like to avoid so if you want to do such low-level things, you have to go all the way down to the Ethereum Virtual Machine. Okay, this is kind of the path we want to take. Now let's talk about some new features we added in the last year. This contract here is a simple database that stores people by an identifier, a name and some flag that says whether they are owner of something and you have a function there which allows you to add one person to the database. It already looks quite repetitive but it gets even more complicated if you want to add a function that can append a list of people into that database. The problem many people run into is that you kind of have to create an array out of these three things here and what you usually do is that you add three parameters which are each an array. This of course creates the problem that you have to check that all of them have the same length because you have an ID that corresponds to a name and this flag. This looks really, really ugly but fortunately now what you can do now is, oops, sorry, what you can do now is this and we added structs as a central feature to the ABI which allows you to actually just directly pass this struct from JavaScript into the contract and remove all these weird repetitions. And of course you can also return an array of structs. So this is not yet available but, yeah, thanks. So we hope to get that fully functional by the end of the year. So and the way what this was possible was through a change in the compiler itself. So we could have done that the old way but we decided to do a full rewrite of the ABI encoder and decoder and this is a snippet of the Solidity Code Generator and how it looked before this change. Yeah, this is also really, really ugly. The EVM is a stack machine and because of that you have these pop and dup operations and in the code generator you constantly have to keep track which variable is where on the stack and because of that we have these commons and it's really, really complicated to understand what this code does and also complicated to write new code. And this is how it looks now and it leverages a new intermediate language we introduced called Yulia. Alex talked about that I think yesterday or the day before yesterday so I will not go too into depth about that but you see this is really, really readable. It has variables, you know what happens, you can use names, we have for loops and so on and what you also see is you have these angle brackets here and this is because this is an intermediate language mixed with a very, very simple string templating engine to make it more flexible. What you see here is the full function to do any encoding of an array into the ABI encoding. So it does handle memory arrays, call it arrays, storage arrays, arrays of arrays, arrays of constant length, arrays of dynamic length and so on and the way it works is that for example here at the top we have length equals length fun and at the time of compilation, this length fun is replaced by the name of the actual function to retrieve the length of the array which is of course different for a statically sized and dynamically sized arrays. Okay and a language becomes more and more useful, the better tools are available for that. We already see that in the questions that were asked in the previous talk. Remix got gigantic updates. I think Jan will talk about that later today. We now can track variables, have breakpoints, see references of variables and I think soon can also rename variables and so on. We have a way to export the AST which is the result of the parsing step. This allows many new features and one of them is a tool to do code coverage not based on syntax, not just based on lines but on semantics. So for example, is a less than operator actually tested to do what it does. And then a standard JSON IO, this is a way to get more fine-grained control about the settings of the compiler. Yeah, then I have a very special announcement to make and this is that the Solidity documentation that we only have in English for now is now also available in Spanish. So please give a big round of applause to these five people who did that in their free time just as voluntary contributors. I think this is really important to make Ethereum accessible to the world and languages like Chinese or Russian should also have their own translation of the documentation. And I want to spend the rest of the talk on formal verification of Solidity team and whoops. I think I showed this slide to you last year in Shanghai. This is a smart contract and it has comments which allow a formal proof the sum of the balances in this token contract never changes. The way it works is that the smart contract gets translated by the compiler into a language called Y3 and it mixes this translation with the comments you have here. And then you run an external tool on that to create the proof that the balances are constant, some of the balances are constant. But what you see is that there are almost as many lines of comments in this code as there is code. And you also see that these comments use a language that is slightly different from Solidity. So it requires you to learn a new language. It requires you to learn how to use these tools. And this makes it very hard to use this formal verification tool. And the harder it is to use, the easier it is to make mistakes and also it is easier for... So form verification is only useful if people understand what is actually proven there. So the statements that are proven there have to be understood by humans. And if that is not possible, then nobody will use formal verification and it's useless. Because of that, so yeah, perhaps that approach was not so great. So we took a step back and reconsidered and how it looks now is like this. We replaced Y3 by a tool called an SMT solver. SMT solvers are less powerful than general theorem provers. And because of that, this smart contract, in this smart contract, we cannot prove that the sum of all balances is constant. But we can prove that the sum of the two balances that are modified is constant. So what happens here is we have a require statement, which is, yeah, doesn't have much to do with the formal verification. This is just the regular solidity requirements, require statement. And then we store the sum of the two balances in the before variable. We perform the modification. And after that, we check that before equals after. And this is a regular solidity assert. So if the sum of the balances is not the same, then this will throw an exception at runtime. But using the SMT solver, you also get a proof at compile time that this assertion will never be triggered. Okay, more specifically, what happens is that, so you can use this tool with require statements to have expressions that you assume to be correct. And then the tool proves that there is no assertion that fails. There is no overflow or underflow in your arithmetic operations, no division by zero, no constant conditions, no unreachable code, and whatever we will come up in the future. And so let's take a look at a simpler example. This is still an experimental feature. And because of that, you need this first line that activates the SMT checker. And yeah, the function here just takes two numbers and adds them. Of course, there's a problem because we can create and we can have an arithmetic overflow here in this addition. And this is exactly what the, so if you run the compiler on that, then this is the message you will get. And the great thing about this SMT solver is that it has, so it's more limited than Y3, but it has a feature that Y3 did not have, and this is the following. So if an assertion fails, it tells you why it fails. And I think this is really important because otherwise people say, ah, I don't know, it doesn't work, but okay, let's just comment it out or whatever through something added so that it doesn't complain anymore. But this tells you why it fails and kind of forces you to think about this addition and think about why it might create an overflow and then take the necessary steps to prevent the overflow before it happens. There are, so currently what people often do is create runtime checks about overflow, add runtime checks about overflow in arithmetics, but this can be really dangerous because if you end up in a situation where you have an overflow because of some internal mechanism of the smart contract, then the smart contract will be stuck because it will always throw this exception because of the overflow and you perhaps can't get the money out or whatever. But if you already get the warning at compile time before you deploy your contract, you can think about why it happens and prevent this from happening in the first place and how you prevented this like this. So you add a require statement, which of course in the end has the same effect as if you would just check if there is an overflow, but the benefit is that you see that there's an additional condition that is present about these numbers A and B. And the SMT solver will now see the require statement, take these conditions into account and then check again whether the overflow will happen and of course it sees that a number less than two to the 100 plus a number less than two to the 100 will be less than two to the 256. Okay, yeah, let's take a look at another example. This is taken, this is an actual example from the underhanded Solidity Coding Contest where there was a loop that used an unsigned variable and decreased it but checked against greater or equal than zero and of course this loop condition is always true. That's of course something that can be detected from the type of the variable alone and you don't really need an SMT checker, but yeah, I, this was a simple example to present here. And it can do much more complicated conditions and yes, this is what we'll see next and yeah, this talk was quite dry about programming language theory, so I would like to end it with an exciting math puzzle. So here we have a circle plus circle equals 10, circle times square plus square equals 12, circle times square minus triangle times circle equals circle, what is triangle? Any guesses? So yeah, easy as pie, we just write a small Solidity Program that is equivalent to this puzzle and we add the conditions as require conditions and then at the end a cert falls. So a cert falls sounds weird, why would we do that? And the reason is if the SMT checker can prove, so a failing assertion, so assert false is not bad, it's only bad if it's actually reachable code. So false assertion will not be triggered if it's not reachable. So the SMT checker has to prove to us that this assert false is actually reachable and it's reachable if all the three require conditions above are true. And of course it doesn't just tell us that it's reachable, it tells us how it's reachable, so what are the exact inputs to get to this failing assert and we see that triangle is one. Okay, this kind of shows the power of the SMT Sol we don't really know yet, so it's still experimental and not fully finished yet, we don't know how it will behave on very complicated contracts, but yeah, we're optimistic and let's see how it goes. Thanks, thank you for your attention. Thank you, Christian. A very quick announcement I've been asked to make, there are items that have been turned into loss and found downstairs at the registration slash t-shirt sales desk, so it's probably easier to go get them now than after close of event. I'd like to next introduce Ethereum Miss Developers, Everton Fraga and Victor Maya, they will be speaking on MIST towards a decentralized, secured architecture. Morning everyone, I am Everton Fraga, I'm here to talk about MIST project. Alex Vendicendi couldn't be here, he's about to have baby, so maybe next time. Well, we're here to talk about MIST project. First of all, let me go back here. Okay, why MIST? What's the vision of the project? It is to host the Web3, Web3 projects, the land of the decentralized applications where you could access websites that live actually in no central server, using peer-to-peer technologies such as Swarm, and having the blockchain as the backend. Let's browse through the past versions. Okay, at the first DevCon, there were no MIST. So that's why people would execute transactions that executes my contract methods, only in command line tools. So it was really developer-oriented, and well, no graphic interface. So you had to be a command line guru. Therefore, no dApps. By the time of DevCon 1, we had Ethereum Wallet, which was the foundation of the dApp space. It was the first one we built. It was more like an advanced tools for specialists. You had to click around and get to know all the application. And it posed it as a dynamic interface for contracts. Through auto-generated, based on the ABI of the contracts, you could have executing contracts with all the parameters, and just like a Boolean, and you int, and then you would execute methods. Well, it did its job, but for the general use, there were some features missing, of course, such as, that would require you to have Ether, for instance. Then by the time of the DevCon 2, we had released the MIST beta, which was more like a Firefox or Netscape navigator as the beginning of the internet. Focus on the enthusiast user. It presented the full power of the web for smart contracts. So you would, from your JavaScript application, from your website, you would trigger transactions, and then MIST would handle it. Here you can see a confirmation window about the execution of a method in a contract. We have these parameters that could be parsed via an ABI directory with BIPyper. So yes, that led to many other things. So you could create your own congress at a contract and then build an interface out of it. But you know, as the blockchain started to grow in size, it was becoming less and less practical for the users to have the whole blockchain synced. So yeah, this is one thing that we will talk later. Throughout this time, we had the ecosystem has grown like crazy. Throughout these three years, we have been downloaded many, many times as well. So I'm here proud to share with you that Ethereum Wallet and MIST combined had been downloaded more than 2.6 million times. So that shows a bit of the size of the trouble we have, because we are the most user-far-front of Ethereum projects. And then we have to deal with all those sort of problems that came as well. Well, in order to solve that and organize all the project, we did a MIST summit in Rio, where we get to have the whole team. And we talked about a lot of the problems we have the whole team. And we talked about lots and lots of things. So it was sort of a whole week thinking and working. So here's some proof of workshops for you. Notice that all those different clothing, so it was really a whole week. Yeah, and that was our team at that time. So yeah, we came up with really lots and lots of experiments. You know, there's only some interface-wise experiments. So let's get to the deliberate features this year. First and foremost, our main, main concern is security, because, well, we have a browser that handles private keys. So it gets, you know, it's not so simple as would be a simple website that doesn't handle anything related to money, for instance. Well, let's put a rib on this because it is so important. So we've made an extensive audit by Q53, which is a really, really cool German company. Those guys are really skilled. And they managed to find 22 issues with varying severity levels. So we have some critical ones, high, medium, and low. All of those were fixed by us. As soon as they reached us, we were ready to fix. And we increased our tax suite, so no regressions here. And also we had some really important if you're bound to program submissions. And here I'd like to thank Juno and Newho Kim, really, you know, thank you. And we had also some other exciting features, such as the swarm integration in beta version. So a user now is allowed to click on file, upload to swarm, then choose a file, upload it to this swarm instance that's running locally in his machine. Then the file is in the swarm space. The swarm will compute the hash out of it and communicate with other swarm instances, copying the files over them. Well, that's actually the seed of the Web 3, right? You could upload a website, then access like this, pasting the same hash in your browser. But, well, here's one thing. Swarm comes with ENS integration, so you can have this. That's one of my favorite features. And speaking of ENS integration, we also did some of them in the wallet. So, well, of course, you're able to transfer ether to a certain address, ethionfoundation.eth, for instance, or add a custom token, just putting the symbol of the token, then it will search on a previously made list and get all the details. Then, after these three years, as I told you, the sync was sort of a problem for the users. We got many, many people saying, my balance is two zero, I'm seeking here for hours and I can't still see my stuff. So, we have now integrated, missed with the like client, still in beta version, but we are aiming to reduce the syncing times by an order of magnitude, and it's still using the version one of the protocol. The version two is about to come, maybe right after the dive call, so keep posted on Goetheum, team, and missed. We have also built in remix IDE, so we're seeing Hudson-Jameson, we'll see Ian's talk right after mine, actually. And now we have the possibility for a developer to write code, run on the main app or on the test nets, and that's quite powerful. The developer is also able to debug transactions to see exactly what steps that transaction made and what were the states of the variables. So, we also did a really easy way for the developer user, which is solo network. You will make use of the Goetheum DAV flag, so you can have your own private Goetheum blockchain. So, this is not actually a solution, it's the real deal. You run an empty blockchain from scratch in your machine, and you can manage mining from the interface. So, that is a missed aiming for a larger adoption of developers. We also had, by the end of last year, Windows installers, so people got happier, and now some planning features. Account management is one of those really, really important ones. Which would leverage the power of standalone transaction signer, enabling remote node management, and easy to switch between nodes. Here's the deal. If we want to use Infuda, for instance, for any reason, we would sign those transactions from within the signer. All those account keys would be held at the same directory, and we could even switch between nodes. Could be Goetheum, PyEthereum, or any other. Having all those keys managed by mist couldn't be even harder at wallets. So, this account management would lead to having those multiple Ethereum clients. So, you could use your own favorite node, having native support to Ethereum clients. It's actually a JSON manifest, which we already did. So, it only has a gap for now. All those accounts will be managed by mist. So, if you switch nodes, you would still see all the same accounts. So, we're under actually a major factor being led by Mark, who's there, maybe. Yeah, Mark. Show yourself. He's not here. Hi. Oh, here. Yes. Mark is our new addition. He's a redux book author, a really skilled developer. So, he's fixing internal state issues for now, which is mainly the foundation for major features to come. We're also thinking about having a sync jumpstart, which is something really awesome, in order to fix that zero-balance issues. So, you would start connected to a remote node. So, you would see all your balances, all your stuff like real-time. Then you'd have a background sync. So, that would progress, progress, progress. When it comes to the right point, you would switch over. So, you would switch to like-lined or full node over choice. There is also this important news for the DAP developers that we're planning to isolate local storage between networks. So, you would have different scopes to work with. So, the DAP developer wouldn't be worried anymore about having mainnet storage and testnet storage. And, you know, also transaction specter, which is something, you know, it's time for us to have. We would show pending and past, no more per DAP setup, because as taking the wallet as an example, he handles all its transactions and pass and history. So, that wouldn't be necessary anymore. All with ABI lookup. So, you'd see once that methods are on the directory search, that would be so evident. And, you'd see perfectly the transaction details. And, speaking of the Ethereum wallet, it's time for a change. So, back then, it was one of the most ideal ways for you to kickstart on your Solidity project. But now we have some powerful tools like Remix, and maybe we don't need some features that we had in the past. So, now we see as the idea way of starting as a Solidity development is having, well, in Remix itself. So, we're planning to deprecate some features in order to have more simplicity. And, we're planning to have a new wallet contract. There are some other audited and solid work around. So, we're planning to, in the near future, to change that. Well, this is about developers as well. Yeah. So, we plan to have very integration with Remix, improving private net integrations, kickstart some Puppet magic. And, of course, we're totally open to suggestions. So, you can guys reach me out before. Before lunch, or maybe something. Speaking of the ecosystem we're trying to build here, I think it makes a lot of sense if we could have some DAP trust meter, because there is a fundamental question about this. Should DAPs have access to your HTTP? If DAPs could be run from Swarm, does that make sense, even sense, to have access to HTTP? We all know the web now is full of trackers from our clients. And, those trackers feed the multi-billion markets, taking advantage out of our online habits. And, once DAPs are hosted in Swarm, users will be able to decide whether or not a certain DAP would have HTTP access. And, although the blockchain has already proven itself secure, of course, social engineering and trickery are important problems to deal with. And, we'd like to invest some time into anti-fishing mechanisms, and using some sort of reputation system or blacklist subscriptions that users will be able to easily manage. So, yes, here at DEF CON 3, I present to you this summary. We've got hardened security, smarter Gath updates, we're no longer having to release missed versions for each Gath update. ENS integrations, Swarm Beta, Deli Client, Remix integration. So, there's a key takeaway, which is, missed is a full browser that makes you run a full node. It can be also a light node, but the thing is, you should, for the good of the ecosystem, run your own node. Well, this is our current team. And, we also have some, many endorsers of contributors. So, I'd like to clap a little bit for them. Those guys help us with translation, with many bug fixes, and lots of suggestions around. And, there's one more thing. Remember that I told you about the workshop back in June. We're working together for that whole week, and it's gonna set about many, many things. And, Victor Maia kickstarted a new track within the team. So, I invite him to stage to talk about his new project. Victor, sorry about that. So, hello everyone. Now, we are gonna show you something new. So, are you ready? I think everyone here dreams about a centralized web. A word of abundance, where there are no companies, where nobody owns anything, that are just public apps and dolls, that are un-easily forkable, resilient, and free. Can you imagine that word? Well, of course you can, if you use that thing. But, for back end services. So, what about the front end? What about user interface? Well, it has been two years since our launch, and yet, most apps are still just centralized companies with tokens. They are hosted on central computer. They use centralized APIs. So, where is the decentralized web? Why it's not happening? Let's talk about mist. Whoops. This is our code. As you know, it's not in a great state right now. Mist is a little bit slow, it has some bugs. Of course, you're working to prove it, and we believe you can make it much, much better now with more on your team. But, even if mist itself was perfect, even if that thing was flawless, will that be enough? Well, what about those? Browsers like mist depend on a huge web stack. There are millions of lines of code that we do not control, and you already had two major vulnerabilities because of those things. So, the point is, how can we prove those things to be secure? Well, we can't, and that's a serious problem for a browser that deals with real money. Don't you think? So, and even if that was not the case, if those things were perfect, what about those things above? Well, let's talk about JavaScript. Okay, sorry, I think I have some problem with this controller. So, would you use that code on your app? No, really, think about it. Is it safe to use that thing on your app? Well, of course it is, it's just a pure function. It's as simple as it gets. There's nothing potential unsafe about it. So, what about this one? Would you use that thing on your app? Well, of course you would not. I hope you would not. I mean, you don't know what Square.js does. It could do anything. For example, this is a valid implementation. It's correct, but there's something extra there. It also alters the global app tree object. So, this isn't, like, this is not cool. This is the kind of bullshit you can do in JavaScript. So, by the way, this is not only about private keys. Hacking the global scope of a app can cause it to, for example, show misleading info, track user actions, mine cryptocurrencies on your computer. So, here's a lesson. You should never import JS code. You did not read. It's not safe. But, oh, oh my God. I think, let me just try something. Okay, I'll just use the arrows. But we know that the devs read all their imports. Like, this is not a real problem because the devs are doing all that audit work by themselves, right? So, let me show you something. This is a list of web2.js dependencies. Each one of those lines is an independent package with a lot of files, perhaps hundreds of lines of code. This is the first, this is the second, the third, all those are web2.js dependencies. And my question is, have you devs around here read all of them? Any of them could be hiding something like this anywhere. So, the point I'm trying to make is, for that and many other reasons that I don't have the time to explain, the web, as we know it, was not made and it's not ready for crypto. So, what it needs is not another web browser, but a brand new thing made from scratch for that centralized web. We need an answer to the question. How would the web look like if it came after a film? And to answer that question, we started the Moom project. Thank you so much. So, this is not another web browser, but an actual decentralized app engine that is lightweight and performant. Use the scripting language with safe modularity so people can share code without needing to audit everything. That language is kind of like JavaScript, but without the bad things. It's more enough to be formally proven secure. And if those words sound a little bit scary, that just means a computer, not a human, can verify that the whole thing does not have a single vulnerability. And that's kind of a big deal. So, in short, oh my God, sorry. So, in short, this is what I have and this is what you're building. By the way, I'd love to elaborate on how those things are possible, but sadly I don't have the time for that right now. So, sorry, they have to be for another day. And finally, some of you may be thinking, but I like the web, the web has so many things, are you just like throwing the whole web away? Of course not, I'm not that insane. Everything's web compatible and Moondaps also work inside a browser and Moondap can be compiled to JavaScript. In fact, you could even use Moondap as just a safe module system for JavaScript. So, for example, here I import Moondap in normal JavaScript code, then I use Moondap to import some library from IPFS or Swarm, and then I use that library inside normal JavaScript. So, you don't actually need to use Moondang to benefit from it. And it also works on other languages, so you can think of it as kind of like a safe code in sharing tool, not an actual language. You don't need to use it. So, demo time. This is a video of the Moond browser. It's the web version of the Moondang. This is a 100 kilobyte HTML file. So, yes, it's really small. You can use it kind of like Mighty Wallet, but with dApps. So, let's open a dApp by pasting its IPFS hash. As you can see, this dApps is pretty simple. There is a title, there is an image, and there's the black number. It's connected to Ethereum. So, let's see how its codes look like. One of the cool things about Moond is that you can always recover readable code from its bytecode. So, it's not actually plain text as we do on the web. We recover readable code from the bytecode. Above that, we have imports with our just IPFS hash. That's good because with that, you can make sure that those imports will never change. There, we have the main component with some things like its name, its local state, and a title. There is a fetch function. It gets data from Ethereum. Since Moons appear language, we need to use something called monets to do that, but you don't need to worry about that because that's very hidden. And finally, we have the handle function. It's kind of like React. So, I guess some of you may be familiar with that already. So, let's change some things. Here, we replace Moom by DevCon on the body. We also do that on the title. And now, I want you to pay attention to the hash bar, to the title above that. As you can see, not only the title, but the hash itself has changed. That means that new depth is already published on IPFS, or in other words, we just hard fork it, that's depth. That's kind of cool, don't you think? Of course, it is a very simple depth, so let's open something more useful. This is a token wallet. There's no written on this account, so let's send some data to it. As you can see, the confirmation window is a little bit ugly, but the transaction was signed and sent. So, let's select the previous account and see the code. Okay, so one of the cool things about Moom is that it has a component-based architecture. So, you can get inside any component that is inside any depth. So, for example, here, we access a subcomponent of the wallet's depth. And we can also go all the way down to the most basic functions. See how everything's hash-addressive. So, one of the cool things about Moom, too, is that, for example, if an application used that same function, or an equivalent function, it will download the same thing. So, there's a lot of sharing, and very good usage of IPFS resource. So, okay, let's go back to the wallet. As you can see, our reader has arrived, so that's kind of cool. And for the last thing, let's open again the token table. Now, there's a question. This is a component from the wallet's depth. How hard would it be to use that component inside the HelloDefConDep that we just made? Well, let's see. So, we copy that hash, we go back to the HelloDefConDep, we import it by using that hash. Oh, sorry. And I actually go back, so because I want to show something, then I press the arrow on the wrong timing. So, again, here I import the token table. I replace the shoot component by the token table that I just imported. I remove the moon image, so it's the same place as the moon image would be. And we click above that, it's forked. And as you can see, that component is now working inside the HelloDefConDep. And doing that kind of thing is always safe. So, we can always take a component from some other depth and put it in your depth. And because moon is pure and made to be secure, you can always do that without worrying at all. So, in short, a depth engine that can be formally proven secure. As scripting language, we are sharing code is always safe on a truly forkable web. That's the moon project. If you want to try it, we have a live demo at that URL. Thank you. By the way, just a small little point I would like to make, that whole thing is actually decentralized. So, there is no central computer anywhere. The back end of the depth is Ethereum. Code is downloaded from IPFS. So, you can just try it, do something I don't like and there's not anything that me or anyone else in the world could do about it. Because moon depths are actually publicly forkable, decentralized, resilient, and free. Exactly like smart contracts are. As I think that depth should be. That's it. Hello, good morning. Next up, we have Jan and Rob and they'll be presenting dark developments using Remix, Mist, and Geth. Hello, everyone. Yeah, so today we will be presenting Remix with Rob to pay here. So, I am part of the Berlin CPP team in Berlin and so I am a developer of Remix. If you already have internet now, you can browse Remix.etiam.org and we have a version there. And so there is also like documentations and you can also browse our chat, the GitHub chat slash Remix but you can also go to Remix-Dev and it's a more developer chat. So, today I will be most of the time presenting what Remix is and what are the new features of Remix. We'll go over like what happened last year after Shanghai. We'll go over all the new features that we have and we have one kind of important features which is actually a tool. It's Remix-Dev. And I will present so how we can use Remix together with Geth and Mist. Then we can take a look to the link that we have between us, the CPP team, Remix-Remix and the community. There is a lot of link, it's nice. Then Rob here will talk a bit about a new UI changes in Remix that will be deployed soon and then we'll go over what's next. So if I want to resume a bit what Remix is, I would say just a 3D editor first that contain a basic syntax highlighting that contain auto-completion. So you have basic IDE features, right? So you can just write smart contracts in 3D team. It contain runtime environments which is completely integrated in the browser which means that when you will create transaction, when you will send transaction, everything will be run inside the browser. But you can also, if you like, use Remix with any external nodes. Like you can plug Remix with Geth or you can plug Remix with Parity or the CPPusClient. And then first important features of Remix is the code analysis. So as long as you are writing code, we will just analyze the code and then Remix will just propose some warnings and display some warnings in order to improve the code and in order to avoid mistakes. So this is Remix and I will go over a basic use cases now. So you can input contracts. Here this is a default one, but that's all. You have two important stuff happening in the right panel which is the compile tab and run tab. So if you look at the compile tab, you will have some informations about the compilation results. You will have some informations about the static analyzer. For example, here you can see that the compiler gives you one warning and the static analyzer gives you two warnings. So you can check in real time what you could do and you can check if there are maybe some mistakes in the code. So you just write contract and you compile a contract. Then you might need to run a contract. So we'll just go to the run tab and there are several options at this point. You can use integrated VM in the browser or you can plug Remix to any external node. And for example, in this slide, you will click on create. That will create a new transaction and you will be able to see the result in the terminal below. So you can see that below, I can see the new transaction, you can see the from field, you can see the transaction hash and you can see a bunch of other informations. If you want more informations about transaction, you can then click on the next, on the details button here. And you can see more information like execution cost, transaction cost, value, the byte code, the deployed byte code. And then important feature is the status field here. This is a new feature that has been released with the base engine release. And if you want to have more informations about the execution of a transaction, you can click on the debug button here and you will be able to start a new debug session here and you will be able to go through the execution step, step by step. And yeah, so this is a really basic use cases of Remix, you write contract, you verify contracts with the analyzer and then you can debug the contract, you execute and you debug the contract. Yeah, so I will go a bit outside of technical stuff now. We have this here, three new contributors in Remix, which is very nice. We have a lot of new users, you can join the channel and we have a new interface. Well, the interface is not completely new, but then now we have a tag guide, thanks to Nina, that allows to have a more cleaner design and we are really proud of it now. So yeah, and you can just ask them questions. There are Nina Breznik, Sarah Puff and Robby here. They love to answer questions. Okay, so I will go over some features that have been deployed in Remix lately. The interesting one is the static analysis. It's just a bunch of modules that will run along the compilations and that will check if there are mistakes and if the code can be improved. For example, the second one from the top is check effect and that will check if there might be any rentancy issue. For example, if you look at gas and economy, the second one, there is this on local calls. That means that it's not very nice. If you call a tunnel function to use this dot, it's better to just call a function with the name of the function because it will consume more gas. So it's a bunch of modules that are here to facilitate the tests of the contract, the verification of the contract and that can as much as possible forbid to make mistakes. Yeah, thanks to Sarah Puff. We have this time now, which is, I think, very nice. What you can do here, you can see transactions as we have seen earlier, but you can also input JavaScript code. So you can input script. In this example, you can see that there is a call to get block number, like web3.eth.getblocknumber. This is JavaScript code, by the way. So you can just input scripts and you will have the results in the console. You can also listen on network. That means that either here will be displayed transactions that are executed from the remix UI or maybe you want to here display any transactions. So you will check listen on network and you will be able to see all the transaction mines in the network and you will be able then to debug and to inspect them. Yeah, the usual debugging features, you can see the state of the contract. I mean the 3DT state, the decoded state and you can also see the local variables. One example here. And yeah, you also have breakpoints. So you just put the breakpoints in the code and then you click on jump to network and you will be jumped to the network. Yeah, this is the basic ID features, but that makes the life easier, I think. Yeah, one really nice stuff that we have since a few months is the swarm integration. Very cool. So you can then publish on swarm. So you see that on the upper right of the image here you can see the details of the contract. If you click on publish on swarm, you will just deploy this bunch of season stuff in swarm, which is the version of the compiler used to compile. Which contain some settings and which contain also the source code that has been used to compile. So you just click on publish on swarm and everything will be pushed on swarm and then you can reuse it in remix or you can also reuse it in any kind of applications that use swarm. In remix, you can use the swarm integration directly in a source code. Here you can see import token from and then a busy URL. Yeah, so I think this is really important feature because that leads us very more decentralized way to develop depth. And yeah, that's most of the one very nice feature that we have since a few months. So now we'll go back to what the remix is. The remix is a web app. And as a web app, it's a bit hard to keep your code because the code is stored then in the browser. And if you lose storage, if you clear the browser, then you will lose everything. So it's very bad. One solution will be to use a file that are in your local system, but using the API of Chrome or so on, but it's a bit complicated maybe and maybe we don't want to do that. So one solution will be to use remix. What remix do basically, it will share a folder between remix and your local computer. So you will say to remix G, okay, I have this folder. Please let me access this folder from remix ID. This is the basic use case of remix G. The other use case is just why I'm here now today. This is the interaction between remix, mist and guess. Now I will just say to remix a G. Please start guess, start mist, then use this folder to store the chain data, maybe load a front end somewhere and that will just create a new development environment inside the computer that you can use. So what I will do, I will start remix G that will spawn a new blockchain or you can use an existing one. You will share a folder between your local computer and remix ID. You will maybe if you want serve a folder in your computer so you can browse DApps and you will start guess or mist. Or if you don't want to start mist, you start guess and you can then use your normal browser to get there with MetaMask for example. Now I will just give here a small test case. I am here, I will listen on network. I am in mist, but I am browsing remix inside mist. I will check listen on network. At this point, all the transaction will be displayed in remix. Then I go back to the front end and I will just play a bit with the front end here. I will input some value and I will click on give here. That will just create a new transaction. But until then it's fine. I will validate the transaction. I will wait a bit. And remix D by the way will automatically mine stuff. So I don't have to start to mine. Everything will be mined automatically. So that will be mine. I will go to remix D, sorry remix. Then at this point, I can see transactions happening here in the terminal of remix. And I can inspect the transaction. I can see the execution cost. I can see some other information about transactions. And I can also debug it. Yeah, so this is one specific use case that you may want to have. I mean that you have your contract. You feel that your contract is okay. But then you want to test your contract and you want to use your contract in your front end. And at this point you will have to go back and forth between the front end and the contract. Like, okay, you play with the front end and then you realize that you have to modify something in the contract. So you will go to the contract and then you go to the front end again and to the contract again. Yeah, this is very long. But with that, you can easily switch between and you can easily make modifications in the contract and see the modifications in the front end. But maybe you don't want that. Maybe you just want to have a contract and to deploy the contract without taps and it's fine. So these are resolve very specific use cases. Remix and the community. So you can browse, remix, now. You can access the chat, you can discuss with us and you can ask questions and you can ask for new features, of course. If you go to itaskin.io, you can also use Remix Debugger. You can also use MetaMask with Remix and a very nice feature that's been deployed. Maybe not deployed but that is current in development is a way to debug transaction from MetaMask. So basically MetaMask will replay a transaction inside MetaMask and will give the trace to remix. So you can then debug any transaction from Ringkubai or Opten or any other app. Infura, important too. This is another way to debug transactions. So Infura is a bunch of nodes that are maintained by them and everyone can query those nodes but then you cannot now query debug endpoints. You cannot debug transaction using Infura and I would really like this to be happening because that will allow a bunch of nice stuff. Swarm, ENS integration. You can now browse, remix, id.ech in Swarm. And this is very important to move very more centralized way of doing stuff. Mist, we already saw that. And NPM modules which is another important features or advancement I would say. We really want to split up remix in different parts so the community can use it. Because now if you want to use only Static Analyzer you will have to pull the whole remix and you don't want that. You just want to pull the Static Analyzer. So we need to split up into several modules. What's next? I think I will let Rob speak now. He will talk about some new life changes. Thanks. Well, all that technology is kind of cool but what we're gonna talk about now is aesthetics and themes are coming to remix. We've made a dark theme and I like the idea of themes because we're gonna be aesthetically flexible for both your eyes and your taste but also for your application. So it's gonna be easier to integrate remix into your projects. That's the next button. So we've made a dark theme is using the Metropolis color palette. And that's the compile tab. And here's the run tab. And in this Metropolis edition remix we're gonna highlight Metropolis changes as they get reflected into the remix tool and also Solidity changes and the UI changes as they get reflected in the tool. So you'll be able to navigate remix better with these new updates. And also because this is a great platform for learning Solidity we're gonna be having a lot of tutorials and instruction for beginners. So you can start learning Solidity with this tool because it has a test environment and you're not gonna lose all your ether. Thanks very much. See you soon. Next up on the millennia we'll be talking about Dapp Hub. Guess I'm too early. Oh, there we go. So I'm gonna 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 that somebody's gonna 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 gonna 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 sub shell, 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 to 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 gonna 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. You wanna 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 gonna 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 I 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 gonna 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 gonna 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. dsmoth is providing access to this auth modifier. And dsmath is providing access to this wmall 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 wmall 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. Think of them as boxes. Again, I'm reusing metaphors here, but what we're doing is we're taking components, putting them on the blockchain, taking more components and wiring them up. It actually looks a lot like hardware design. Pre-fabricated 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. 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 type 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 is 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 really 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 DAPs. 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 DAP hub. 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 daphub.com, all the links are there. Check out our tools, check out our chat, daphub.chat, for a lot of interesting stuff. We are here to create free software for DAP devs. Thank you. Thank you, Andy, millennias of DAP hub. I, back by, oops, back by popular demand, we have Rain Revere, speaking on real world smart contract development lessons. Please give a hand for Rain. So nice to be back. Good to see you all. So my name is Rain Revere, and I'm a smart contract developer. I'm the lead architect at Shapeshift Prism, and I'm also the co-founder of Maiden. I've been doing smart contract development for a couple of years, and our team has learned so much along the way, and it's really an honor to be here and to be able to share some of those lessons with you. And it's especially an honor to be one of the few women up on stage. I'm a trans woman, and I love this work, and the community's so amazing, and so it's such an honor to be able to share some of this expertise and really dig into the details. So when I was thinking about what I could possibly share, I wanted to give something that was really practical, and so this talk is gonna be pretty straightforward. We've got lots of things that we learn doing smart contract development in the real world. So that means production level, handling lots of ether on the live network, which as you can imagine, has a lot of responsibility that comes with that. So what you can expect from this talk is that I'm going to go from low level to high level. So all of these are pretty practical tips for all the smart contract developers in here, and I'm gonna start with the code and we're gonna go over some details, some patterns that I've learned and our team has learned from, and then we're gonna end on some higher level patterns, especially when it comes to being a leader on your team. How do you lead as a smart contract development engineer? So first, the low level patterns. Central logging is something that took me a little while to find my way to, and when you design your smart contracts, you wanna modularize things, right? We all know that as software developers, but there's some quirks in the EVM, at least at this time, that you may not think about ahead of time, but actually lead to a system that is more maintainable and is able to respond and communicate with your server or whatever other architecture you have. And one of those is what I call central logging. In a multi-contract system, logs or events that are fired are really an important way to track what's happening on chain. All of your off-chain activity is going to be based on different events that are firing. And when you are firing events from different contracts, you generally have to monitor those events separately. So each contract, you're gonna be watching those events. And so if you have a multi-contract system, there's actually a lot of benefits to using a single logger contract. And so when you have a single logger contract, all of those events will fire from the same contract and are easier to monitor. So let me just show you how that looks. So here's an example of the logger contract. And what we have here is a whitelist that maps addresses of contracts to a simple Boolean that says whether it's been approved or not. So this is where it handles multiple contracts. So those addresses are of contracts and you have a modifier that's a simple requirement that the sender is indeed in that whitelist. And so the modifier whitelisted is provided here. And then you can have any event. Here the event is called registered. So that's the red text with the two superscripts. And the registered event is simply forwarded from the log registered function. So if you have the owner, which is provided with the owner super contract and then the only owner modifier, pretty standard, you can have an owner contract that is able to register all the contracts in the system. So contract A, contract B, contract C, all of those are being authorized contract to be able to register those. And if that authorized address was set in creation, then you know exactly who has the ability to register new contracts. And then those contracts have the ability to call log registered or any event. So that's an example of central logging and that's been super helpful for us to be able to handle large numbers of events from lots of different contracts in a multi-contract system. The next one I wanna show you is the idea of modular libraries. So libraries in Solidity, if you're not aware already, are a way of deploying code once that other contracts can use over and over. And when you have a multi-contract system or you're deploying a new contract for every iteration of something, there's a lot of gas costs in that. And if you can reference, if you can link a library, that's gonna save a lot of gas compared to implementing, compared to deploying all of the contracts again. So libraries are known as well known to provide that gas saving mechanism. And the idea of modular libraries is the idea that you can link multiple libraries together in order to provide some abstraction layers. So these are all like architectural patterns for you to have more maintainable smart contract code. So what does this look like? The modular library is one in which the contract itself doesn't have to know about all of the different modules. And so it's a way to encapsulate functionality within a library in order to have some separation. Now libraries are linked and all of the calls end up appearing internal. So this doesn't actually provide, this is more of an organizational strategy and architectural strategy than changing the actual access levels. So here's an example. For the Prism Projects, we have a library called Prism Lib. And there's a lot of different pieces of data and libraries that have functions that operate on that data. And as a way to break it into smaller pieces, one good method is to have a data struct in each of the libraries that's defined in each of the libraries. And then that can be included in the contract. And so you have nested levels of data. So the struct is defined, you can see in the blue with the number one is the data struct. And then that's being expected to pass into each of the functions. So the rebalance function on the Prism Lib is going to ask for the prismlib.data. And then the nested nature comes from the fact that Portfolio Lib has its own. Portfolio Lib we can assume is that Lib B and it's being imported somewhere else. So Portfolio Lib we can assume has its own data struct. So Portfolio Lib can be accessed, the functions can be called in Portfolio Lib and the data is contained within that Lib. And so there's an abstraction there. If you notice, we're not passing the entire prismlib.data to the rebalance, Portfolio Lib.rebalance function. We're only passing self.portfoliolib. So the second red instance, number two. And so that way Portfolio Lib.rebalance or any other functions in Portfolio Lib don't have to know about anything else in the data. So this ends up being a pretty standard abstraction and hiding mechanism, but something that we haven't seen a lot of out in the wilds with library development, but we found it to be a really great architectural pattern for prism. So now we get to the last of the low level patterns that I wanna share with you. And this is a higher lower level pattern and this is an idea that has been shared in other talks here, the idea of the blockchain as a court system. And this didn't come to me until much later in the development of prism, but the opportunity to save a massive amount of on-chain computation exists when you treat the blockchain as a court system or an arbiter. Which means that you assume that parties are acting in best, in good will, in best interest, but you have a mechanism that if something goes wrong, if one party says the other is not doing their, not fulfilling their obligation, then you can run an actual smart contract as if you're bringing it to court. And when you run that, when you execute that smart contract, then you're using the blockchain to orbit, to be the arbiter of that transaction. So what does that look like? So here we have a contract. This is just a general, you have some users and there's going to be a counterparty, the other end of the deal. And you're using the smart contract, the naive approach would be to execute everything on the smart contract. When you have arbitration built in, then instead, as I described, you assume that both parties are acting cooperatively and correctly, but you have the mechanism in place for a dispute resolution process. So the top interaction here is where the user, through the smart contract, interacts with the counterparty. There's not any execution, there's really nothing happening there, there's not code that's being executed on chain, maybe just a hash that's stored that both parties can use to evaluate off chain what's happening. So user A maybe sends some ether to the contract after a certain amount of time, the counterparty is expected to send ether back or some transaction occurs. And at this level, it's really up to the counterparty whether they wanna do that or not. Now, if the counterparty doesn't do their part, you have a time window, a week, a month, whatever the time window is, where the user can file a dispute. And that's all on chain. So there's a time window, the funds are locked up. And so imagine user B has a problem and says, yeah, the counterparty didn't do their job. So they send a dispute resolution transaction. And this time, whatever business logic needed to be executed, which could be quite expensive, is going to be fully executed. And because it is deterministic, the winner of the dispute will always win. So the beauty of this is that the incentivization is such that if you know you're going to lose, you would never do the wrong thing. So the counterparty has zero interest and the reason you force that incentivization to be aligned so strictly is that you say if you lose the dispute, you basically lose all of your money. So you punish the person for behaving against the expected behavior. And so when done right, there's really no incentive to go against the expected behavior. You have user A acting, expecting a certain thing back from the counterparty or the counterparty doing their job. The threat of the dispute resolution process incentivizes the counterparty to do their part. And the beauty here is that you're not actually executing the full contract logic on chain. It's just user A doing their thing and the counterparty doing their thing. So I see this as a potentially huge pattern that can be used across smart contracts in order to optimize, reduce execution time. And this is something that could be put to good effect on a lot of projects. Okay, how's everybody doing? You still with me? The developers are. The developers are like, yeah, this is cool. Okay, so we have some higher level patterns and these are for you as well. These are also for developers. If you spend more than a couple years working in the software industry, I hate to break it to you, but you're gonna have to do some things other than coding. You're gonna have to learn some other skills. And some of those are gonna be technical skills and some of those are less technical. But what are the higher level patterns that allow you to be successful as a smart contract developer? Not just when you're in solidity land, but when you're working with your team, when you're making judgment calls, when you're making important decisions about the direction of your product that the rest of your team is looking to you for. So one is something that I call role analysis. This isn't a technical term, but role analysis, how do you analyze the roles in the smart contract? And this is something that you can use. This is simply an approach to smart contract development and design. And you can use it at any stage of the process. So if you're designing a smart contract from scratch, who is interacting with the system? That's the main question you're asking here. Who is interacting with the system and what are their incentives and how does the behavior, how are their behaviors going to derive from the functions that you expose to these different roles? So I use this both in the design process, but I also use this throughout the entire career of the smart contract system when you're iterating and you're adding new features, there's always going to be adjustments to the behaviors of the different users and the different roles that are interacting with your system. So to be a really good smart contract developer, you have to understand all of the roles of individuals interacting with your contract, what their different incentives are and how that affects the overall functioning of the system. This is like the essence of the game theoretic nature of decentralized smart contracts. So just some examples. The Prism contract for Shapeshift Prism has a few simple roles. It has a buyer, a seller and an oracle. And with Prism, the buyer purchases a contract, a portfolio of different digital assets. The seller is putting up collateral to ensure that those assets can be paid off depending on whether the portfolio goes up or down. And then the oracle is another entity that's providing the prices that determines the value of the portfolio. So different roles and even these simple three roles have involved a high level, a high degree of analysis, an ongoing analysis to make sure that the trust implications are well understood as the contract develops and becomes more sophisticated. Another example is assault loan. Let's say you were doing a loan that was backed by digital assets that was collateralized by digital assets. In this case, you have a borrower, someone who's borrowing cash and then you have a lender who's offering that cash but then locking up the collateral. And in this case, you have salt as a kind of multi-sig arbiter to make sure that if anything funky happens with the other two, salt is in there and can have the last word. This is an example from a talk yesterday. The liquid pledging contract was a really, I thought really a brilliant idea to combine fund management with liquid democracy. And here there could be many arrangements but a simple arrangement is to have a giver who's providing some ether and they want that to go to a good cause or a good project. They don't have time to do that themselves or they want to trust someone else so they delegate that to another role and that delegate is gonna choose the project and eventually a reviewer is gonna say, yes, these milestones have been accomplished and that goes through. So this is a simple concept but it goes really far and it really is what can separate someone who just knows solidity from someone who can design, maintain and scale smart contracts on a live network. Context dependence is another skill that comes with experience and is something that is really valued on a team and by this I mean, analyzing when one action is true in one situation and the same action might not be true in another situation. I know this is really scary for a lot of you. I didn't get into development to deal with fuzziness and ambiguity either. I love really straightforward and deterministic systems but the truth is any complicated problem is going to depend on a lot of context. So one example in this space is that you hear a lot of best practices. Best practices are great but when they turn into hard and fast rules you can really miss out on the nuances of the situation. So one I see a lot is send versus withdraw patterns and the advice out there is to always have the user withdraw. Never do a send. So there's like push versus pull, never do a send. And I actually don't like this advice because it's often just taken without much thought. Why don't we do a send? Well, we don't do a send because there's vulnerabilities if you're trying to send to multiple people. You have to be aware that any one person their fallback function could throw, they could use up all the gas, they could use up most of the gas. So there's risks to sending to multiple parties. Okay, I understand that. There are also situations where maybe you don't want for the user experience they don't have another transaction. You don't want them to have to do that transaction. So maybe the send would be appropriate in those cases. Keeping in mind this dictum of it depends I had a professor in grad school who this was in my counseling program and it was beautiful. Every time anybody asked, well, what if you're working with this client and they do this, what should I do? She always answered. She thought about it and then she said, well, it depends. And that would be her answer every time. So with skill and experience comes an incredible awareness of context. So I encourage you to think about context dependence. And lastly, I wanna say leadership in blockchain at the developer level because contracts are immutable, technical debt is much costlier. So when you're making decisions as a lead engineer, you have to make a lot of judgment calls because that code might be on chain for a long time. And that's something to keep in mind. Thank you so much. I'm gonna go over the patterns just to name them. We talked about central logging, modular libraries and arbitration as architectural patterns at a lower level. And then at the higher level I hope you can take some of these concepts away about leading your team, being more dependent on context and then bringing role analysis to everything you do. Thank you very much. Thank you, Rain. Next up is the MetaMask team. Kumavis, Frankie and Dan and they're presenting MetaMask dissecting the Fox. Excellent. Oh, I'm Kumavis from MetaMask and today we will be dissecting the Fox. Are there any MetaMask users out there? Does anyone have it? Wow, that's amazing. So yeah, we'll be looking at its part pieces and figure out how it ticks. To begin, let's take a look at the eyes and the brain, what we see, what we know. First of all, we know we must be doing something right. We have just shy of 200,000 users and growing at quite a pace. We're in Chrome, Firefox, Opera and recently Brave. Not in Safari, they have not adopted the standards that we rely on. They like to think differently over there. More on Brave, not just Brave support but actually Brave integration. If you go to a Web3 enabled DAP in Brave, it'll bring up that bar at the top recommending that you install MetaMask in order to use Ethereum applications for all Brave users. This is fantastic. Some other statistics, despite its popularity, MetaMask still represents about 5% of the transactions on the network by volume. We had a peak at about 10%. And I think the other wallets are about the same, maybe Muse a little more but there's clearly a large amount of activity on the blockchain that must be automated, perhaps exchanges or mining pools. I'd love to hear if anyone's done some data analysis there. In the past year, there's been some fantastic DAPs that have come out that play well with MetaMask. The new state of the DAPs website is fantastic. And you can even search by MetaMask compliant DAPs by just adding the MetaMask filter. I encourage you to check that out. To sort of gauge what is the most popular DAPs right now, we have some data from Infura. In first place is Ether Delta. In second is Oasis DEX, both token exchanges. Obviously tokens have been very popular, so no surprise there. In third place is MetaMask itself. We're a bit noisy and we are constantly tracking the latest block updating balances and whatnot. After that is the ENS registrar. ENS was a big hit this year. After that, we got Token Factory. Token Factory is a nice little demo DAP. You can create a token, sending it around. Clearly, we have lots of people experimenting with Ethereum, trying to get an idea of how to use it. After that, there's the SI, the simple stable token experiment, and the wallet.etherium.org. This is actually the official Ethereum wallet interface, and you can visit that in your regular browser with MetaMask, and it works. Then a long tail of various other projects and experiments out there, including 127.0.0.1, obviously many developers out there cranking away. We also had a successful security audit this year. They said, in sum, the MetaMask project should be considered safe and secure. That's great. To keep up with the rapid growth, our team has grown from four to 10. Much thanks to the design by Christian. He did the original logo. Thomas has helped us out with testing, and James has really saved us doing support, answering user questions. If you send us an email, he's who you're talking to. Also, the Kylken team has helped us out very much with a new look and feel, and I have to thank Consensus for making this possible. So yes, let's take a look at the fur and skin, the look and feel of MetaMask next. And for that, I bring on Dan from the Kylken team, also known as Dino Dan. What's up? I'm Dan. I am part of the Kylken team. We do apps and interfaces for blockchain companies. You can find us at kylken.io. I will talk about version four of MetaMask, the new UI, some token management features, and our new responsive layout with multiple form factors. So as you can see, the new UI here is completely redesigned. Shout out again to Christian for some great work. It looks a lot better and is quite a bit easier to use. We hope you like it. Look out for the rollout in the next couple of weeks on the Chrome Store and several other browsers. Next up is Add Token, which is a feature that we've cleaned up a lot. As you can see here, you can do a string search for your token name and token symbol. This is actually an open source project you can make a contribution to called eth-contract-metadata. Right now we're searching for maker and we can add it as you can see here. We can also add a custom contract token as you're aware of, we're gonna automatically fetch the token metadata. So this is the zero X token contract address. After you've added your token, you can send your tokens, which is a new feature. So I've got some Kiosk here for our company, KioKan. I can send my tokens to my friend and I've got a new gas tool tip to customize the gas price. We're all about responsive design, of course. So you've got two form factors here, mobile and desktop. On the left hand side, you have account and balances, and on the right hand side, you have transactions. And on the top right, you've got your familiar network dropdown and account settings. And next up, I'd like to introduce Frankie to talk a little bit about MetaMask in the browser and what the future holds. Can you guys hear me? Oh, perfect, I can hear myself. Hi, I'm Frankie. I am a core dev on MetaMask. I'd like to thank Dan one more time for coming up and speaking for us. So let's talk about building dApps with MetaMask. We recommend this pattern today if you wanna build a dApp. As you can see, it's quite a bit of code and personally I think it's a little clunky and that we can do better. I've wandered too far from the laptop to wander back. I would like to announce MetaMaskera. MetaMaskera is a module that you can require in your build system or drop in as a script tag like so to use the CDN. MetaMaskera finds the environmental provider and works with miss, MetaMask extension and parity. We'll extract it for you. And if we actually go back here, we can see how that works. And you just call create default provider and it will get it for you. If there is no environmental web three to extract the provider from MetaMask will, or Maskera connects to the new MetaMask web app at wallet.metaMask.io. Let me just hold for a second there, guys. That means your users don't have to download MetaMask anymore. To demo this, I've built a little dApp here that we can see how the flow of what it will look like using Maskera. Go and create password. Sure, we're all used to this. Of course, we've kept our lovely fox. It's also a little slow. Sorry, I didn't speed it up for you guys. We'll generate a unique account. Ignore the beta notice as we always do. Also just scroll straight down and then do seed phrase. Get a good look at that seed phrase, everybody. And just as a little added bonus to protect our users, we've added a little game to make sure that you've backed up your seed phrase correctly. Go through and click things. Now, of course, I'm only human. Thank God I wrote my seed phrase. As you can see, it's not gonna let me confirm that because it's wrong. So we can all awkwardly sit here now and watch me try to figure it out. There you go, you're doing a good job. It's okay. She gets nervous on stage, you know? Ah, there we go. And of course, it takes you to this deposit page, which I'm going to skip for the sake of the demo. It takes you to the account detail screen and we go back to the dev. Click bonk me. And if you can see here in a second, the MetaMask window is going to pop up just like you would see in the extension. So let's talk about how that works. MetaMask, as you know, it is an extension and provides a single background process for different applications to talk to so users can use the same keys. We've created a very similar flow here by hosting MetaMaskera, we'll inject an iframe into the webpage that talks to the service worker underneath wallet.metaMask.io. The service worker contains the MetaMask core, which also talks to the UI. And moving on. I would just like to remind everyone also that MetaMaskera is a developer beta and if you find any issues, please report them, we greatly appreciate it. Now I'd like to welcome Kamavis back on stage to talk about the evolution of MetaMask. Hello, excellent. Yes, let's talk about where this fox is headed. Just a small one to begin with. Debug trace transaction. If you saw the demo for remix.etherium earlier, it's a fantastic tool for debugging the transactions behavior in your contract. But previously it's required test RBC or especially configured geth node in order to use it. And soon to be pushed to production, you can use it right in MetaMask against any network you're pointing at. Another RBC method, our first new one, the first one that has been implemented in MetaMask and not yet parody and geth. This is ETH sign types data from EAP 712. This gives us a human readable structured data signing format. You can specify some parameters and their value. And when they are intercepted by MetaMask, here's a little mockup. We can display that sort of that form data before you decide to sign or deny. And this is very useful for state channels. Moving on to some internal organs. The heart to really key management. We've broken out the key ring controller and one of our key ring types, the hierarchal deterministic key ring. And you can use these as modules if you're building a JavaScript wallet. And if you build other key ring types that match that API, they can be added to the key ring controller or added to MetaMask if we build the requisite UI for them. So they slot right in. So yes, wallet developers, please feel free to use these modules, take advantage of our security audit. We know many people have been waiting for hardware wallet support, contract proxy account support, and coming soon the account abstraction from the next fork. They can be implemented using those key ring types. Another internal organ of MetaMask is the blockchain data source, the provider. We've been experimenting with a IPFS based a zero and light client. And what would that look like? Well, it would fit right into the network menu in MetaMask like you're used to. Select Ethereum via IPFS and it works just like you'd imagine it would. However, since selecting an item from a menu doesn't really make for a great demo, we have a data visualization of what's happening behind the scenes. So this is still a very early stage. It's naive, it's doing lots of back and forth. What you see here is it's lazily loading nodes from the state graph in order to provide data for multiple instances of the Ethereum virtual machine running in parallel. Currently it's looking up some data on the OMG token, a couple of accounts balances, as well as the total supply. The blue is the state graph and the green is inside of the contract, the contract storage. If you have some questions about that find me afterwards, I'd be happy to answer them. This is still very early stage experimental. We've spun up a project called Mousticala to organize some of the efforts to bridge Ethereum and IPFS. Sounds like many other projects have been working on this as well. So we look forward to working with them. And yes, the foxes howl. Many people ask you how can we collaborate? We're very open to this, please just reach out. In particular, if you're doing a token launch and you are recommending MetaMask to your users, please get a hold of us. We've had many, many support questions over the past year and sometimes don't know where to direct our users to actually get the information. So please take care of your users and one way you can do that is to reach out to us. Another howl. How to contribute. Of course MetaMask is all open source. We would love to have your contributions. We're looking forward to integrating with Gitcoin, GitToken and all these incentive schemes that the ecosystem has been creating. If you really like MetaMask, we're also hiring, reach out to us. Oh yeah. We also would like to highlight a few other things in the peer-to-peer ecosystem. As Joseph Poon has said many times, the blockchain should be sort of the supreme court. We should only go there as often as necessary. And there's many elements of this decentralized ecosystem that frankly don't need a blockchain. And so I think that we need to explore some of the already existing projects that are doing a great job there. I'd like to highlight the Beaker browser. This is an awesome peer-to-peer browser. It's based on the DAT network, which is comparable to IPFS. It lets you share and serve websites peer-to-peer as well as create your own websites. Patchwork, which is one interface on the Secure Scuttlebutt network. This is a very highly featured social network that's completely peer-to-peer and doesn't use blockchain at all. This is fantastic. I think you'll enjoy exploring its community. So please check it out. Oh yes, and one more thing. That mascara that Frankie demoed, it works right now on Chrome for Android right in your browser. So try that out. Thank you.