 You'll miss that. Basically, K is a project for writing down programming languages in. So it's a language-building language is what I tell people. And so we have built the languages C and Java and JavaScript, and we're working on C++, and we have Python, and we have a lot of other big languages, and also some network semantics, and stuff like that. So basically, once you write down your language in K, you have both a formal specification in terms of a human-readable document. And you have a range of tools, essentially, that you can use for experimenting on both your language design as well as for running programs and things like that. So you get a parser out of it, an interpreter, you get a model checker, a deductive program verifier, and we're working on some new exciting tools as well. At IC3, the EVM semantics was already finished, actually. It started as kind of a side project in a class, and someone approached us and asked us to finish it and gave us a convincing amount of money to do so. And at IC3, basically, I just extended that semantics to include some kind of higher-level language constructs in EVM. So it was just a few days working on that, but basically I added things like while loops and if statements and assignment and local variables and structured control flow to the EVM, and then it just had a small compiler down to EVM itself, and I called that language EVM Prime. The compiler is written all in K. It's about 250 lines of literate K codes, so most of it's actually documentation. So it was fairly compact, and that just kind of speaks to how easy it is to build new languages in K. And right now, that project is being used to, so we're writing tests for EVM Prime, essentially, and then we're also extending it to kind of, our goal is something like a Viper-minus-minus so that we can very easily compile Viper contracts into this EVM Prime or this Viper-minus-minus thing, and then the remainder of the compilation can kind of be well controlled and well understood. And then also out of that, what you'll get is all those tools for Viper contracts. You'll get a program verifier and a model checker, symbolic execution engine. All those tools immediately provide for contracts as well. And then hopefully also EVM Prime will serve as a nice compilation target for other high level languages. One of the other things we were thinking about maybe doing was targeting LLL, if people are familiar with that, as another slightly higher level language, and then that would kind of give us the benefits of having all the LLL tool chains available to us. But we're open to suggestions in terms of how people would like to see that evolve. And we'll keep on working on it and building more languages on top of EVM directly. So I think that's about it. Any questions real quick? Cool, yeah. So my project was writing secure smart contracts. And we had probably the biggest team at the bootcamp. I think there were like 10 people on it or something like that. And it was sort of meant to be a dual purpose project, both educational and constructive for the community. So how many people here have heard of HACTA site? Anybody? Use HACTA site? OK, a few of you. So I think a great way to train people, train solidity developers and smart contract developers in the ecosystem on how to write secure smart contracts and how to write proper code that lasts a long time, is by actually having them getting their hands dirty and breaking other smart contracts. So the first thing we sort of did was we got all of our 10 people together in a room. And we had them write an ERC-20 with no other instructions other than that. Just sit down and write an ERC-20. And then sort of me and a few other people went through and audited their ERC-20s and pointed out to them all of the ways in which we could possibly break them. After that, we had them fix their ERC-20s and go through the re-auditing process until they had correct ERC-20s. And then sort of the second half of the project was to build out this platform, HACTA contract. So you can access it at hacktaskontract.io. And the way it works is there's five or six example contracts on there that are intentionally vulnerable. You deploy them on the rinkabee testnet. All you have to do is give it your rinkabee address and then have at it, try to hack the contracts and see if you can actually break these things. So future work directions, there's a few features missing from the site, which you'll see if you try to use it. I still think it's totally usable and fun today. So adding those in is obviously sort of priority zero. After that, I'd like to add in all of the wonderful submissions we had to be underhanded Solidity Contests, which you guys heard about earlier today in the main room, as well as examples of all the past hacks. So I would like new Solidity Developers to sort of come in and be able to reproduce the DAO hack themselves and write that attack contract. And I think that by doing so, we're sort of educating people on how you can write smart contracts incorrectly and indirectly getting them to write smart contracts more correctly. So I think it's a super fun approach and I think you'll feel good if you log on and try to break a few of these things. Cool, hey, I'm Nate. I work with Deloitte on a project called Peace Relay. So first of all, to start off, who here is sort of BTC Relay? All right, a couple people. The general idea is that there's a smart contract on the Ethereum chain that imports block headers from Bitcoin. And once you have block headers from Bitcoin in a smart contract, what you can do is you can provide proofs of transaction inclusion in those blocks to the Ethereum blockchain. So an interesting use case might be something along the lines of, oh, pay me money to my Bitcoin address, and if you do, I'll give you ether in a trustless manner. And so this is pretty much what we can do with this idea of relay contracts, like cross-chain relay contracts. So the project that we worked on, Peace Relay, essentially, we're trying to do that for any two EVM-based chains. Essentially, relay contracts between two EVM-based chains. Over the course of Bootcamp, we built out one of these. And we were actually the pretty big stuff here, the first ever people to move Robson ether onto RinkV. I know, huge. And the idea is that you lock an asset on one chain. You can then provide a proof to the other chain using this Peace Relay contract that that asset was locked. And what it does is it instantiates an asset-backed token, the ERC token, that backs the asset on the other chain. You can move that asset around in the second chain however much you want. And when you want to eventually move back, you can burn it on this chain, and then provide a proof over here that you've actually burned it. Other than that, there's a couple other interesting applications, which we'll talk about in a minute. So the immediate application is that you can move ETC or any other EVM-backed coins, like NEO and Q-term to Ethereum. And so that all the decentralized changes on Ethereum can trade between tokens and this coin. So another application is that now you can actually move private coins in some private chain because of the Ethereum Enterprise Alliance. So many people are building private blockchain with their own asset. So you can actually move the asset in the private chain to the public chain, and then trade between this coin and other ERC-20 tokens. Can you add something about that? So the other interesting thing that you could possibly do is you could imagine kind of, so the idea is like, with piece relay, one EVM chain can become aware of another EVM chain. The other interesting thing that you might be able to do is kind of point the piece relay contract at the chain that it's actually on. And that might not make much sense, but kind of the idea is we can make the EVM more aware of what's actually happening in the EVM. So for example, as kind of a spin-off of this project, one thing that kind of came out in the summer was essentially a gas oracle. And so kind of you can imagine that the EVM kind of becomes aware of how much gas is actually being used on the EVM. The reason that's interesting, you can imagine if there's this much gas used, if there's more than 50% of gas used in the last 100 blocks, extend the time lock on this state channel time-up and other interesting things like that. Right now, piece relay is being maintained by two different teams. The first team is Kyber Network and DAPBase. And the second one is, I guess, Consensus in the Ice Relay project. And from Kyber Network's side, we are planning to release some beta version of piece relay by the end of this month or early next month. So please give in touch. Any other question for piece relay? All right. So in typical runner-up fashion, I actually prepared a presentation. So let me just run through that real quick. So our project was front-running Bankor. It was done by myself, Fissi Pereschi, Yvonne Bogati, and Preeti Kasseretti. So quick, okay, that's not working, that's cool. So quick note, so this research, so we did this at IC3 and then we published the research on October 10th. At the same time, we worked with the Bankor team before we actually published to address the vulnerability and put out some fix so that it wasn't still vulnerable to this. I just wanna point out, the Bankor team was cooperative and analyzing the tack, pushing out a fix. So I wanna give props to what it's due. It's still in early space. People mess up all the time. Blockchain development is really hard. So that was cool. So what is front-running? Front-running is a term that originated back in the stock market. Back in the days when trades were executed on paper. So literally what would happen is a broker would receive a large buy order from a client and they might say this out loud so that people could hear and they would go walk over to the desk to perform the trade. A malicious trader would basically hear that this was going on or see this was going on and literally run in front of them to put in a buy or sell ahead of time to profit and sort of sandwich their transaction in between. Now you can do the same thing on a blockchain. If a minor user sees an unconfirmed transaction in the mem pool that they can profit from, they can squeeze their own transaction to come in front. So essentially you're profiting from a beneficial reordering of the transactions. Now as a minor, this is pretty easy because the way that mining essentially works is that you are sort of the leader for a moment so you get to decide what goes in that block and so you can reorder transactions however you want if you manage to mine that block. As a user however, you can actually manipulate where you go in a block by changing your gas price and most mining clients will sort mine transactions by the gas price. So if you come in higher than somebody else, you'll come in before somebody else in the serialized execution. So many blockchain market protocols are vulnerable to minor front running but it doesn't seem to really happen very much in practice that we can observe. Plus miners can only front run in blocks that they themselves happen to mine, right? So unless we're coordinating among a big mining pool if I'm a malicious miner, I only get to front run if I happen to mine a block which is very, very rare for any individual miner. However, if your protocol can be front run by random users, that's really bad because that means that any user who's sitting on the blockchain looking for transactions can front run any transaction that they want to. So Bankor was known to be vulnerable to minor front running as many marketplaces are but we demonstrated that it was vulnerable to user front running meaning any user on the network could front run Bankor transactions and make money. So how does Bankor work for those of you who are not familiar? Bankor is basically an automated liquidity provider using a smart contract. It gives you deterministic pricing by maintaining a constant reserve ratio, okay? So long story short, if you buy, the price goes up. If you sell, the price goes down. That's the law of the land for Bankor, okay? So what that means is that if I know someone's gonna buy, I know the price is gonna go up, great. So the attack is pretty simple. You launch a geth node and you write a little bit of Python script to basically monitor the mem pool and see what transactions are going in the network. If you can tell that the transaction is one that qualifies as being worth front running, which that's basically what that's doing. Then all you do is you increment your gas price a little bit more than what they paid. So you can see one G way more than them. Then you launch the transaction and if all goes well, you should have front run them. So running simulations, we show that over a two month period of July and August, with 100 ETH principle, you would have produced $35,000 in return for front running transactions on the main, assuming that the market or the people in the network didn't react, which is greater than 100% ROI over that period of time. We also showed that because Bancor is a protocol that can be used by many different tokens, the smaller the token market cap, the higher your ROI would be for front running that market. And so if there were a large number of tokens that were using Bancor at that time, you would have been able to make even more. And so we also front ran a single transaction on the main net just to prove that this was in fact doable, which we did. We returned the delta that we made to the person who originally made the transaction and then didn't front run any further. So how can you mitigate this kind of attack? So this is kind of endemic to blockchains, but there are several ways to try to mitigate it. So one thing you could do is force all buys or sells to specify an acceptable price range. So you could say, okay, I'll make this transaction, but only if the price offered by the market maker is P plus or minus some Epsilon, otherwise cancel the transaction. If you do that, this can't be front run by other miners or users because you're guaranteeing yourself a certain price. However, this leaks important metadata. If someone front runs you and then your transaction is canceled, they kind of know, let's say you were gonna buy a million Bancor, right? Well, okay, maybe you're transaction not canceled, but they know someone's trying to buy a million Bancor. So they know that Bancor is gonna go up. So if they buy a bunch of Bancor and they know eventually you're planning to buy, they know that they can just wait for your buy to come in and then they can sell. So this also significantly limits your throughput. So if lots of transactions are happening on Bancor, then it's very hard to ascertain how wide that Epsilon should be so that your transaction doesn't sort of get canceled innocuously, right? So otherwise you just have to accept some margin of front running that you're okay with if that Epsilon, you know, obviously if you're buying you're okay with the price going down, but you wouldn't want it to go up. So it's not a great compromise, but it is better than nothing. However, what you can do is you can set a maximum allowable gas price for the contract. So essentially what that does is it puts an upper limit on what people are allowed to pay to try to get in front of line of each other, right? So this is nice because it can't be front run by users. However, it's still vulnerable to minor front running because miners can do whatever they want. It's not really, you know, they're not beholden to accepting these rules. So it's also vulnerable to transaction flooding by malicious users, but this is expensive and difficult in practice and not really something that people have seen. So this is a solution that bank were settled on. It's a decent compromise between UX and security. Everything still happens in one transaction. Just a few extra parameters you have to send up. Now the ideal solution would be some form of commit reveal. So in a commit reveal, these are well known for voting schemes. In a commit reveal, you first commit to the transaction you're gonna make by sending a hash of the transaction plus some nonce. Then you reveal the transaction and nonce into subsequent block. Unfortunately for a commit reveal to work, it has to span multiple blocks to actually make a trade. So this is kind of undesirable, right? Like, you know, in the span of two blocks, things can change. It's just kind of a slow, crappy UX. But this is the safest scheme. Now doing this naively is still vulnerable to certain attacks. So Submarine Sands was actually worked on by Laurence Breidenbach, Phil Diane, Ari Jules and Florian Tramair where they propose a scheme for accomplishing this securely which is a lot easier with the Create2 opcode which is offered by EIP86 which is not gonna come out in Metropolis unfortunately. So we're still waiting on that. We're also exploring other practical commit reveal schemes that are possible with current opcodes. So that is front running. It was me, me, Prithi, Yvonne, special thanks to Ari Jules, Ido Bentoff and Carl Florish for helping us with our research and of course to IC3. Thanks. Thanks guys.