 before we get started I just want a quick show of hands. So how many of you out there? Yeah there we go. Quick show of hands. So how many of you out there have done any kind of ethical or you know wink wink unethical hacking of financial applications. Any kind of all. Okay good. So yeah I've been focused on these things for like 13 years and I've seen some really crazy stuff. So now out of you guys who have done that how many of you have thought that the code was so beautiful so flawless that it didn't need even the slightest bit of human intervention you know once it rolled out of the desk right everyone right yeah I'm sure. So now imagine for a moment that that financial code couldn't be changed. You know once you put it out there it's just it's out there you know. So if it has any huge gaping flaws or anything that's the way it's going to stay for eternity. So that's sort of what goes on in the world of smart contracts okay. There's no updates, there's no patches, there's no revisions. There's ways to point to other programs but once you put it on the blockchain by its nature the blockchain is this immutable thing right. So if this code is expected to move money around forever on its own it probably needs a little more attention than the usual financial apps you might have looked at in the past. So that's why this is an important field. And we're sort of getting it on the ground floor still here. Think about if you had gone to a web app hacking talk around the year 2000 you know that's the idea here this is very new to a lot of folks. So I'm going to try and you know ease everyone into it a bit. So I want everyone to be able to get something out of this talk. So no I'm not just going to explain how Bitcoin works that's silly. But I assume you guys know that. But I'm just going to explain some of the quick differences and what makes Ethereum different, better and a lot more usable in terms of things like smart contracts. So everyone's aware of Bitcoin yeah we know that. So Satoshi met his goals right he wanted to have the whole distributed ledger to avoid double spend you know have had the computational proof of work make this thing actually be of some value. And some altruistic goals because half the world doesn't have a bank or access to a bank so now thanks to Bitcoin they do. But with Ethereum we've got something different going on you know it takes the idea a little further creates this this idea of a Turing complete system the EVM the theorem of virtual machine that runs over the entire globe this one big mega computer that you can access and do things with. So it can save state it can detect changes to info it can remember them. It can intelligent handle interactions between users control flow programming so it could run smart contracts which is why we're talking about it. You know there are some companies building smart contract like features over the Bitcoin network but it's not quite the same thing. So what's a smart contract you know real simply so it's a program right it consists of business logic it runs on the blockchain it's semi-autonomous you know you can think of it as this like thing that just runs on its own which sometimes doesn't really bring comfort to anyone. So it can move value it can enforce agreements it can remove repetitive labor which everyone's all for but again it cannot be patched I can't stress this enough so it is important to really take a look at this code before you put it live. And reality you're limited only by creativity you know you can make escrow systems that hold money in place when it checks for terms you can create new tokens people think about tokens is like just extra coins but you've been using tokens all your lives I mean if you have frequent flyer miles for example that's kind of like a token like a limited set usage so smart contracts let you create ones that have purpose like that. It can handle real estate records you know if a country has an unstable government a smart contract approve you own something enforcing it's another matter but it could at least prove it digitally. It could do things like paid people when work is done trust funds wills you can even imagine something like Airbnb or Uber without the company behind it you know you can have these smart contracts negotiating for people so no one takes a cut when you take a drive or you stay in someone's room. So it's kind of a neat idea. So why should we look at smart contract security well I could literally think of a billion reasons. If everyone remembers the Dow which was a little over a year ago basically it was a decentralized autonomous operation and organization it was designed to operate like a venture capital fund letting you move money in and out. A flaw was found in May 2016 and no one really did anything about it and June 17 a hacker used a recursive flaw which we're going to look at in detail to make splits inside of splits and keep siphoning money out in a race condition without checking the balance. So 3.6 million ether was stolen back at the time they were reporting it accurately that it was you know a decent amount of money but if you look at how ether has gone as high as 400 or three something at times you know it's pretty much if it happened today it would be close to a billion dollar hack. So that would definitely make even bigger news than it did a year ago. Smart contract security is not going away it's not a problem that's you know last summer. It's something that's going to very much affect the future. And what's funny is I'll show you how you can prevent similar theft like that with just switching two lines of code as we'll get to. So more recently we had another smart contract attack. So 30 million reasons are good too. So basically parody was hit and there was a multi-sig wallet that allowed people to swipe 32 million dollars from a few ICOs. It's another ridiculously simple flaw that we're going to look at in this talk. But the idea is there you know people put so much money into these things and they have them be responsible for so many critical assets that to code them poorly is just not acceptable in this day and age. So a quick caveat there's no zero days here you know you can't always easily identify where the first time something was discovered but we're going to be talking about like I said imagine you've gone to web app hacking talk like around the year 2000. I'm going to try and introduce as much as I can in this time about what you should be looking for. There's no customer code that's going to be shared. I haven't shared customer code you know accidentally 13 years I'm not starting today. So you're not going to see anything from like real engagements. I'm going to use like sanitized examples and things like that. But this is about generating methodology you know I want you guys to be able to go out there and try and get involved in this especially if you spend a little time learning solidity which we'll get to in a second. And no I don't think smart contracts are that smart. I don't think they're going to like take over the world or anything so you know there's always that fear like I'm sure it must have come up in the talk I just missed. Yeah they're smart but not really that smart so no mega fears here. Okay so solidity. This is the programming language. Ominous Ethereum like looking symbol there for solidity. So it's the one that won out okay. You don't need to program solidity to do smart contracts but this is the one that everyone settled on. It beat out Serpent which is a little bit like Python, Lisp like language. It's high level human readable. It's kind of pretty in its own way I guess. It has some syntax similarities to JavaScript and C so if you have any of that in your background you know maybe you'll take the solidity quite well. And when you write this code it compiles to EVM bytecode. So it's statically typed. It supports libraries, inheritance, complex, user-defined types. It's pretty fancy. So obviously I can't teach you how to code in solidity in this 45 minute talk. That would be kind of crazy. So we're going to focus on the general types of vulnerabilities you should be looking for and maybe you can re-watch this video if you don't know solidity after you learn it. That's possibility too. So it's in high demand right now. I think it's worth taking the time to learn. There's a book coming out next week Ethereum programming. It actually looks pretty good to me so I think some folks might find it useful. If you learn solidity you'll be like the 10th person to do so. So congratulations to you. So it'll be really good too. Yeah we definitely need more. So ethical hacking of solidity is it's usually part of the dev process. Think of it as like a typical code review. So you know Sol files, the .sol files of solidity, they get compiled and they run on test block chains, then on private or public ones depending. So the customer or other environment could differ greatly so you're going to have to definitely talk to the devs about what's going on if you're working with this. So Matt Swish yesterday, I don't know if he's here but he gave great talk on his tool, Porosity. And that's what's kind of interesting because it lets you pull from the blockchain and get back solidity code. That's not what we're going to be looking at here. Here we're going to be having the solidity files handed to us up front just like you would have any other code review. So that's the sort of approach we're taking here. So the first step is definitely look at the solidity files before they go down that process. A good way to do that is to have an IDE. There's a lot of options available. My favorite's Atom. You can actually get a couple of plugins for that. And using it you can actually have highlighting and it can even test compiling which is pretty cool using EtherAtom. Real Mix ID is kind of neat. It's browser based and lets you try and compile code and see if it errors out. So that's useful too. Okay. And yeah, Emacs and Vim have plugins too. I don't want to start like a religious war but they do. Alright. So while you're still learning solidity, you might find it useful to run a parser like SolGraph. It's not a bad way to look at code even when you know solidity too. So it takes the Sol file and it outputs a dot graph that actually lets you visualize the function, the flow. So it sort of like walks you through how the code works just so you can get that big picture view before you even get started looking for the little nitpicky things. So there's another one called Solidity Parser coming out that looks promising too. So these kinds of things are just age, visual age because sometimes code just becomes, you know, like, mind numbing after all, right? So a really awesome tool that came out a while ago was Iante and it got both better and like sort of worse. I'll explain that. So it's a symbolic execution tool. It's designed to analyze theorem smart contracts. It follows the execution of contracts and what's cool is it can actually reach out and analyze contracts that are on the blockchain. You know, you don't have to just work with Solidity files. No, it doesn't give you back a solidity document like Porosity would but it actually could still step through the ones that are out on the blockchain. But in this case we'll be talking about pointing it to locally stored files. So it detects three valid issues and one sort of invalid one. So call stack, basically the call stack attack which we'll talk about later. It hasn't really been valid since EIP 150. But it also detects concurrency bug or transaction order dependence, time dependency attacks and re-entrancy which is the big DAO attack. So that's an important one and it's pretty accurate. I mean it looks like it has like less than 10% false positives based on other people's data and my testing too. It's just a little tricky to set up so warning you in advance. It complains about versions. It wants you to use old versions of things and then you have to do all that crazy stuff especially in Linux or forcing a version. But if you want my honest opinion, you can just use the latest version, get a few error messages and most of the time it just works anyway so don't worry about it. So just use the newest versions of everything. So to that end we're looking at hopefully getting a basic methodology in place. So whenever you start one of these the best thing to do is to talk to the devs. You know, if you come from an app testing background like I do, you'll find that kickoff calls, you know, who really likes kickoff calls, right? They're like the worst. And most of the times it's people explaining something to you as if you haven't seen it a hundred times before. When it comes to smart contracts, take the kickoff call because sometimes there's a really unique or novel thing they're trying to do. Again, we're in the infancy here. So you definitely want to talk to the devs in these types of hacks. They can show a lot of useful info. What does the contract do? You know, what environments required for testing? These are all important things, especially if there's any kind of like private or permissioned blockchain it has to talk to. So think along the lines of threat modeling at first. You have to kind of understand the application a little bit. Then after that you're going to want to plug it into something like Atom, Remix ID, take a look at it with highlighting, really understand if everything's okay. Try compiling it, make sure it doesn't error out. Maybe they give you the wrong version. You know, get that silly kind of housekeeping out of the way first. But then after that you're going to want to start to dissect the code flow. You're going to want to read any comments that are there. Use something like Soul Graph to understand it. You're going to want to run Oyente and cross your fingers and it doesn't error out. It often does. And then you're going to want to verify that the three that are real are there or not if you find them. But of course you're going to want to look at it manually too. And then you're going to want to check for the types of things that we're going to talk about now in the meat of the presentation. All right. So because of how popular the Dow hack is, we're going to start with this. So I'm not going to be dumping all the Dow code here because I don't even think these screens are big enough. And you're sure Lumvia will read it. So what I'm going to do is show how re-entrancy works with a really simplified sample I coded up here. And I call it re-entrancy, original name for a contract. And I'm just going to show the basic idea. So solidity is read sequentially by the EVM. So re-entrancy can happen if the amount transferred in a contract depends on a balance or state that's updated after the transfer is made. So because it's done sequentially, where you do your accounting is very important. Where you tell the program what all the values are. So in our vulnerable code snippet you can see the expendable tokens balance. It's set to zero at the very end. So the line I highlighted there with the little explosion. That's where the dangerous send or of money can go out. And then after that it's set to zero. So if you could somehow repeatedly invoke this function. Oops, sorry about that. If you could somehow repeatedly invoke this function you'll end up pulling the money out before it's set to zero over and over and over and over again. And something like that is what happened in the doubt. So let's see if we can't take some of this re- out of entrancy, you know. If you were to instead switch lines seven and eight. So now the exploding line does the accounting first. Then if any other contract or whatever was tried to try to pull from the if statement there. The money is already zeroed out. You know it's set up, it's all it's a one time thing and it's not going to go anywhere. So this accounting move means token balances are taken care of early. So even though this is tremendously simplified. The idea is that such a small little change can prevent a billion dollars from being stolen in a race condition. It's almost comical, right? You just don't see stuff like this in any other kind of programming. But it really is that simple. So understanding that we'll just jump out here for a sec. We'll do a quick demo, see if the demo gods are smiling on us today. So this is on extended display so it might be hard to control here but if you could see that. So basically I can't see if it moved. So we have a simple program like the one I just talked about where there is a re-entrance condition present. So if you can see it there the balance is being zeroed out in the last line. If you can make that out. So if I were to run oyente against this I should be able to get it to flag the re-entrance. So I'll just do that real quick. I'll set it up and I'll execute it so you can see it. Okay. So once we hit enter it should run. Come on man. Yeah. I'm a bit of a comedian because of course it doesn't show the password. It's running and it shows the true condition to the re-entrance above. So it could run pretty simply. Because of this extended situation I'm not going to run the next part. But I was going to show you how ironically a bit of code that the developers wrote now errors out in oyente which is kind of comical because it's their sample code. But this one actually successfully ran and showed you. So you'd be able to go in and say why is it there and then you can make a tweak if need be. So all righty. So I'll just get that out of the way and we're back. Okay. So after seeing that you should be able to spot it pretty simply in a snippet of actual DAO code, right? So if you look here it should be pretty obvious. Because they're doing the withdrawal function first without doing all the accounting that follows afterwards it's possible for a re-entrance for a race condition to occur. And it's possible to keep hitting that red line over and over and over again and draining the balances down to zero. So that's the basic idea re-entrances. You just have to watch the careful ordering of the application. So what just happened last week with Parity Wallet it's interesting because Gavin Wood the guy that wrote Parity Wallet is one of the four developers of Solidity. So for him to make this kind of mistake was kind of embarrassing on an epic level. You know. So sorry about that Gavin but it really was. So the company basically tries to do browser based access to Ethereum to try and bring it more into usability. He wrote a multi-sig wallet and in theory multi-sig sounds great, right? Multi-signature, extra security. The only problem is Solidity there's something called visibilities. So functions have visibilities. In the case of functions the visibilities could be public, internal, external or private. The problem is if you don't declare them specifically they're by default going to be public. So if they're public that means it could be called internally or externally by anyone via message. So that's not what you want ideally in code. So you could see in pink how in the original version of the code there was no declaration made. In green you could see how they were changed to internal. Of course that happened after a whole lot of money was stolen. So, so the attackers could send a message calling the, it might be a little hard to see this, but the attackers could send a message calling the public init wallet and that function will override the original owner addresses with their own. So the attacker is then able to wrap that function call and pass in his own or her own ether address as the new owner. So in that first step you say hey this wallet's mine. And then with just another simple request, you can use the execute function. And when that happens your private key is used to sign an outgoing transfer for the balance of the account. If you do this ladder rinse and repeat for three major ICOs you get $30 million for your effort. Not bad for a day's work, right? Not too bad at all. So interestingly enough we used the term race condition before. Here this became a human race condition because a group called the White Hat Hacker Group they noticed this too and they noticed it was going on. So they quickly went in and started stealing the money from people who hadn't been attacked yet, from accounts and things that hadn't been attacked yet. And they siphoned off if you add everything up about $200 million and moved it to a wallet to protect it from this attack until the code was patched. But only a few people got that money back so far. So, you know, they promised by the 31st, but the White Hat Hacker Group, I mean if they don't come through that name is just going to suck. You know, they're going to have to come up with a different one. So, another popular attack was uncheck send. It was first discovered in kind of a goofy game but it's still worth talking about. Now you'll find this kind of thing in Ethereum a lot. In the early days of Solidity people would make these silly games like almost like Ponzi schemes or a digital chain letter in the blockchain if you will. You know, that's what they went for. So the idea was to claim a prize. So you would submit let's say one ETH to a game like this and that would make you king of the ether. Now back then one ETH was worth like nothing. Now it would be like handing over $200 but so you hand over this ETH and you're now king of the ether. So for someone to depose you they'd have to pay $1.5 ETH. The contract creator gets a little big off of that and then you get the rest of the money. So you get paid kind of like a chain letter to be bumped out of the process then the next person pays more and the next person pays more. So if it's all fair it's a way to just keep throwing money for I have no idea why but that's the way the game works. So eventually you get more and more money each person who plays. So games like this you're sending using the keyword send and it acts like a method that's defined for every address object. But send can fail it's not fool proof. So ether stored in either externally owned contracts accounts are controlled by human or in contract accounts and these are controlled by a contract like that's what they call contract accounts. Metropolis version of the theorem is going to kind of abstract this but anyway. So in a contract account you can have a generalized error that would cause it to fail and that's basically what happened. Because any time a contract with that was called an error would occur a new person would become monarch but the old person would not get their money. So if you had been expecting to get 2.5 ETH or whatever at that point you got zip and now the new person was king and you were out 2.5 ETH. So again it's a goofy game it's not really serious but this kind of ability for send to fail is dangerous if you're talking about millions of dollars or something like that. So it's important to look for. So rather going to the whole long remediation code in the king of ETH error I just whipped up something a little easier hopefully to understand. So over here you could see the top code snippets called king of losing because ultimately like what's the point of this game right? But so if send fails over here the winner doesn't get the money but compensation sent will be set to true. Again it's the order that gets you in solidity the order of operations here. So if there's a fail it says that that person got paid but they actually never did. That's why at the top there it says compensation sent is true. Now again it can fail if it's a contract that generates some kind of error or some other kind of condition occurs. So to protect the price from being sent into the you know ether you can have it do a check like on the bottom. You can have it do an if check where if it's not actually sent there'll be some kind of thrown error. Now a thing about throw as we'll see in a moment it's being deprecated there's other forms of validation that I'll talk about in a moment but throw is just easiest to show in a slide like this. Alright so back to what was going on with king of ether. Those contracts were failing because they ran out of gas you know. It's a funny thing about gas. So miners are incentivized they're paid to run the Ethereum virtual machine in gas it's like a unit it's a small unit of ether and it fluctuates of course. So you get these little payments but just like a block shaped jeep a block can only hold so much gas and if you try to overfill it well you know you have an exploding station or something like that. So to find out how much gas you can ever have inside a block at any given time you could go to eatsats.net and it shows you a whole lot of pretty you know Hollywood hackery looking tables and things but in there is also an important number. Currently it's a little under seven million so that's how much gas can be in a block. So if you disobey that you're gonna have a problem something like an externally contract sent contract can fail and introduce errors like we said earlier. Alright so auditing contracts requires looking for places where errors lead to unintended possibly costly outcomes. It's not so different from other types of app hacking you know. So you have to look for the order of operations like I've said. If something fails due to an error nothing that comes after might run. So this could be sort of like a unintentional denial of service. There's a lot of problems in Ethereum where something layer out and then everything that comes after is just ignored which could be pretty dangerous. So in this case line 11 is trouble. This is an example taken from the Solidity Docs and attacker could trap the contract into an unusable state by causing the riches to be the address of a contract that has a fallback function which fails. So I think Matt talked about fallback functions a bit yesterday too. So it or even if it just consumes more than the amount of gas that's needed. So that way a transfer like that failing will cause the rest to not work. So to avoid this kind of problem you're going to actually set up withdrawal functions. Patterns in the application that allow withdrawals to happen instead of 4 cents to happen. So if you're overthrown as a riches for example you'll still get it because no errors can happen. In this case the worst you could do is cause your own withdrawal to fail which I don't know why you want to do that. But that's the safety of using withdrawal. Sometimes this is also called push pull instead of withdraw and send. But the idea is the same that you want to intelligently withdraw from a contract. Now before we talk about the next problem I just want to make a little note about the blockchain. There's all sorts of crypto involved in the blockchain in general. But what you'll find is most of the data that's actually put on a public blockchain like Ethereum is it's readable. You can explore it. You can analyze it. So yeah encryption protects wallets. It protects things like that. It doesn't protect necessarily the data that's going up on a blockchain. So games and other contracts that rely on any kind of like secret knowledge or winning knowledge can sometimes be fooled. So if you see people are making guesses on a chain that you're going to make in a game of chance you obviously wouldn't make those guesses if you saw they never won, right? You would kind of observe what other people did and then you would figure out and narrow your chances and make your own guess. So that's not really a great thing. The new metropolis hard fork is going to try and do something about having some kind of transactional privacy. So I'll talk about that in a second. Alright so we've seen examples of how the order is so important. So this was discovered by the guys that made the do-i-ante tool. Transaction ordering dependence. So the idea is that transactions can hit the blockchain in unexpected timing, right? You're not necessarily sure when they're going to go somewhere. So if you have like a simple puzzle like this, on the left there you'll see that the contracts private storage is allocated and initialized in line 8. And then on the right you have the executable code start. That's line 15 over there in which I marked. So transactions invoking puzzle will execute that part and it's anonymous by default. So sender repo, send ether data, it'll all be invoked and sent out. Now the contract owner can update the reward variable. Okay that's kind of like dangerous. You can literally say how much the reward is going to be. And 19 and then it loops back to 18 if you look I tried to make like a little symbol. So then after that you have that arrow going down where it shows the actual payout of the contract. Now what happens if a couple of blocks appear at the same time to a miner and someone is able to influence that and say oh well look someone's about to win. All of a sudden the reward is going to be one ether instead of a thousand ether or whatever. That's kind of a dangerous situation. You can have someone being very very dishonest in that case. They can present this seemingly fair game and then mess around with it. So Oyante is actually pretty good at discovering this kind of like forking possibility and detecting the transaction order dependence bug. The other function I mentioned that they find the other error call stack depth limit. This is no longer really a problem and most people don't know this but as of EIP 150 it's now become exponentially difficult to exhaust gas in this kind of attack. So what used to happen was you would have let's say because of the 1024 limit on call stack someone could create a contract that brings it all the way up to 1023 and then make a request which would be 1024 and cause an error. But because of the EIP 150 changes now what happens is it just becomes like I said exponentially more expensive to do an attack like this. So in the real world I don't anticipate call stack to really be a problem anymore. So it's sort of just like a historical footnote unless something drastically changes. So we saw that there's a lot of Pons of games and things going on in a theory for some reason. And one of the reasons they're so popular is because you could publish the source code, right? You could say to people hey look this game is fair, read it, read the source code, find something wrong with it. And of course no one really does but it's out there for anyone to analyze. So it's possible to make a mistake you know if you use highlighting it makes it easier sometimes to see when you're doing something wrong. But it's possible to make mistakes, some mistakes can happen. But it's also possible to trick people into thinking the code they're reading in a quick glance is actually doing something different than what it does. So in this case we have two separate variables you can see. So you've got payout cursor ID with an underscore at the end and you've got payout cursor ID with no underscore at the end. Talk about something that's incredibly easy to miss if you're just scanning through it. It's like oh yeah, yeah, you're just talking about payout cursor ID. So what happens is the first variable is getting incremented. But the line of code that actually draws the money out is taking it from the other one. So the person who's involved in a game like this thinks that they're contributing to a fair game when in reality their variables ultimately being ignored. And it's the other one that just looks kind of similar you might miss is actually getting all the money. Now again, this could happen accidentally, but in reality this is where the ethical and ethical hacking comes in, right? This is where you'd have to notice something like this is going on and be the one to raise the hand. So as I said before, it throws being deprecated. But input validation is a theme that should never leave any kind of app testing behind. You always have to do proper input validation. So now we've got these new, we've got Require which is meant to be used for input validation. It should be done in any user input. So if a user sends something that's not expected, it throws and the condition is false. So that's a good thing. You know, you're getting what you expect. There's also Assert which is neat because it can also check for internal errors or if a contract's reached any kind of like invalid state. So this is far more superior to just a simple throw. Although I didn't want to make examples with these two because I just get too long. So I used a deprecated throw. Sorry. It was easier to show. But this is the kind of thing to look for. Everywhere that there could be validation in a contract, there should be. Again, to prevent any kind of like denial of service or anything like that that we talked about. So a couple odds and ends here. Time step dependence. It's a little different than the transaction order dependence. The time stamp of a block can be manipulated. So watch out for any contracts that actually rely on a time stamp. It can be manipulated, it can be changed, it can be read within 900 seconds to have a different one be valid. So because of reasons like that, you want to make sure that silly things like that aren't being done. Because it's too easy to trick something that relies heavily on time. Business logic flaws and solidity. I expect this to be the next like big thing. People are focused on those little line by line errors. But sometimes you have to take a step back and say, hey, what's this thing supposed to do? And see that maybe it's not really doing what the developer thinks it's doing. So that becomes something worth looking at. Separating public and private, this is really interesting. And Ethereum has taken off quite a bit in the last few months since the Enterprise Ethereum Alliance formed. The idea there is a lot of companies are starting to have private permission blockchains internally that are then communicating with the bigger public block chain. And how you handle that public private data handoff is huge and I think could be a potential attack vector. So something that will be worth looking at in the future. I'm not sure if the JPMC quorum guys are here. But basically the quorum, they handle this pretty well. They have transaction senders that can use something called private for. And it can basically say, hey, this transaction is private for these people. And then after that it uses a hash of encrypted data only. And then it points to the actual encrypted data. So that way no one actually gets access to any information that they're not supposed to have, even though it's all in blockchain world, right? So it's a pretty ingenious way to handle it, so good on them. But basically when you're going in and doing any kind of like test of something that's new, some new interaction, you gotta look at those boundaries, which again kind of goes back to the whole idea of threat modeling. You know, like how is data handled? How does it move through? Okay. So I think it's time for a lot more people to get involved. You know, I'm lonely. No. A lot of people have to be looking at this stuff. So I've become a DEF CON since the Alexis Park days, you know, and I know there's a lot of talent out there. So it shouldn't take very long for some of you guys to get spun up, Ben Gals, to join the fight here. You can get involved in making smart contracts more secure. Because despite its hiccups, I still believe in Ethereum. I think it's pretty incredible technology. They've never missed a dev milestone, which like, I don't know if there's any other project in the history of IT that's never missed a dev milestone. And somehow this young kid metallic made that happen. So good on him for that. So now we're entering what's called metropolis. And yeah, that's actually the 20 silent movie, you know, art. Not Ethereum art, but it's gonna be even more torn complete, if you will. It's gonna have a new revert and a new return data. It's gonna improve exception handling. So that'll be cool for security. Some account abstractions coming which will help protect wallets. It might even help protect them against quantum computing attacks in the future. Which is a whole other topic that if you want to, if you want me to bore you to death, stop me in the hall. And I'll talk about that. It's also introducing ZK snarks, which are these cool crypto primitives. Even though they're again primitives for now, it should in theory allow enhanced privacy and transactions going forward. So even though it's the public Ethereum blockchain, you should be able to actually have some privacy for the first time in the transactions you make. So that's a pretty cool thing. And finally with what's coming, there's Swarm. I mean if you haven't heard about Swarm, please go forth and Google. It's quite possibly the next amazing thing that you've never heard of. If anyone's watched Silicon Valley this summer on HBO, they did their whole trying to have a serverless internet by taking up little bits of data on a phone, storing it, compressing it. Well Swarm is sort of like that where it's gonna be using the EVM to have sharding and files located all around the world with address translation and everything so you can pull it back and get it. It's pretty amazing technology and once it's rolling full swing I mean it's gonna change a lot. So definitely try and get involved and join me in this good new fight. And if you guys want to keep in touch, please do reach out. If you have questions like some little bit of code you're working on, maybe I could take a quick look or something or if you just want to yell at me whatever, it's cool. So definitely reach out and thanks for coming.