 Okay, cool. So today I'm going to talk about a recent project in smart contract security, namely Oriente, making smart contract smarter. This is the John project with my team from NUS and UNUS College. So, okay. So we all know that programming security is hard because especially for complex program because your system or your program may have multiple components and the adversary or the attacker can choose to attack any component and to exploit your system. So that's why people say security can be no stronger than its weakest component. So programming secure smart contract is even harder because of several reasons. So I myself view smart contract as on short programs because you have only one chance to make it right. Once you deploy it, it's really hard. It's nearly impossible to change it if you find any flaw in the contract. And secondly, the execution model of the smart contract is a little bit different. It is executed by the consensus model running on the blockchain. And the third reason is that we use new language which are pretty much similar to the existing language. So often people make some assumption about the language which exists in JavaScript and Python but do not exist in Solidity and Serpent. So that's why we have seen a lot of problems in our smart contracts. For example, the DAO with the re-entersy bug, ether dies with the gas problem, can you ether thrown with the same instruction? So the question that we asked before we started our project is, are there other bugs that we don't know in our existing platform? And secondly, how many smart contracts are there are vulnerable? So surprisingly, the number of smart contracts is increasingly exponentially starting from 2015. So right now we have probably 120,000 smart contracts and we really want to quantify among these smart contracts, how many of them are vulnerable? So there are several challenges. First of all, contract codes are not always available. This is what we see when we write the smart contracts but what is eventually stored on the blockchain is a binary code which is compiled from the high level code. And you can use this assembler to translate the binary code into the byte code but it's still really hard for you to make any sense of this. And secondly, we have so many smart contracts to analyze and if we have someone really good who can read the byte code, it still takes them several years to analyze all the 120,000 smart contracts. So what we contribute in this project is first of all, we identify new smart contract bugs namely transition ordering dependence and time stamp dependence. I will talk about them shortly. Second, we introduce O&T, the new analyzer for smart contracts which is based on a symbolic execution. So O&T can detect all the popular bugs including the known and the new ones. So we run O&T with almost 20,000 smart contracts and we were able to flag roughly 9,000 of them as vulnerable. Okay, so what is transition ordering dependence? So I will use a simple smart contract to illustrate this problem. So here we have the puzzle solver contract which allows the owner to set up some puzzle and then he deposits some ether so that anyone can submit the solution for the puzzle to collect the reward. And if the owner see that the reward is a little bit low and the puzzle is so hard, so he can update the reward to attract more users. So now let's consider this scenario where some users submit a solution which includes some users send a transaction which includes a solution to the contract. So some miners, they include the transaction in his block and then the submit solution is triggered. The users receive the reward if his solution is correct. So this is totally fine. But let's consider this scenario where we have the owner send a different transaction at the same time to update the reward to zero. So now the miners can select a set of transaction in his block and he can freely decide which transaction to include and which transaction to ignore and which order between the transactions. So for some reasons, he includes the transaction which update the reward first and then the submit solution transaction later. So now the update reward is executed first and the balance is set to zero and then the submit solution transaction is executed. Now, although the user submitted a correct solution he still gets zero reward for his solution which is kind of unfair. So the problem in this transaction ordering dependence bug is that the state that the user observe when he submit the transaction is different from the actual state of the smart contract when the transaction is executed. And this can be a coincidence because two transactions can happen at the same time or the time, right? But it can be a malicious scenario because if the owner saw the targeted transaction from the victim which includes a correct solution for the puzzle, he can one second later send a different transaction to update the reward and now the two transaction enter the raise and the owner has some non-zero probability of winning the raise. So that's it for the transaction ordering dependence. Next thing is timestamp dependence. So we know that Ethereum allows the smart contract to access the block timestamp within the contract and really we have seen too many use case of this timestamp. First, people use the timestamp as a random seed to generate their random number. And secondly, they use the timestamp to simulate the real time. And the problem with these two use case is that the timestamp can be manipulated and the miners, they can vary the block timestamp to the value which bias them. So they can totally bias out the output of the execution to their benefit, either in both of their use cases. So in our papers, we propose the solution for both of the problems. So I think you can take a look at the paper if you're interested. Next, I will talk about Ointi, the analyzer for smart contracts. So here's a high level architecture of Ointi which is based on symbolic execution. So Ointi takes the bytecode as an input and then based on the bytecode, we generate the control flow graph. And from the control flow graph, we pass it to the symbolic explorer which will explore all the possible parts of the program. So for every part that we can explore, we set, we forward it to the core analysis which will detect whether the part of the program, which will detect whether the part has some problem that we want to detect. And if there is, we will forward the result to the validator to validate whether the result is positive. So a little bit more about symbolic execution. So this is our control flow graph. We will visit every single execution chase of the program. So given some input acts, we will collect all the part condition which essentially summarized all the execution characteristics of that part. And for example, we want to check this property whether z is equal to x plus two. We just merge all the condition together into one big symbolic formula. And the rest is used to ask whether there exists any instance of the input that certifies this formula. So in order to answer this question, we send the formula to the theorem proofer, which is C3 in O&T. And this theorem proofer, we say whether there exists such input or not. And if there is, it will generate an example for us. So what can O&T do? O&T can detect bugs in existing smart contracts as I just described. And we run O&T with almost 20,000 smart contracts back in May 2016. And we were able to detect all the popular bugs back then. This is the number of bugs for each category. And second, O&T can be used to do the test generation because symbolic execution allows us to cover all the possible parts of each program. And based on that part, we can generate one example input that drives the smart contract to that execution part. And O&T is open source. We just released it two days ago. You can go to that GitHub repo to clone, to fork and contribute to the project. There are a lot of future work that we can do to improve the performance and functionality of the project. For example, we can support more of course. Right now, we just covered a large fraction of the EVM opcode, but not all of them. We can also handle the loops precisely, or we can combine static or dynamic symbolic execution to reduce the rate of font positive. So with that, I want to conclude my presentation. Thanks. Thank you very much, Loi.