 Welcome everybody. My name is Lars Brunies, I'm the Director of Education at IOHK and in this video I want to talk about the infamous DAO attack and how it wouldn't have been possible on the Jelle virtual machine, which has been designed from the ground up to provide far greater amount of security than the EVM. In 2016, in the DAO attack, the attacker exploited a weakness in the EVM and managed to steal more than 3 million Ether. And I want to start this video by explaining how that worked, by using a simplified example that I've taken from this interesting paper, a survey of attacks on Ethereum smart contracts by Atsi, Batuletti and Gimoli. So let's look at this relatively simple smart contract written in Solidity. It's called SimpleDAO and as state it has this mapping called credit from addresses to unsigned integers, which represents for each address the amount of donated and available funds. So the idea is that once this contract has been deployed, people can donate Ether to addresses using this donate function. So they specify the address they want to donate to and put some value into this function call and then the state variable credit will be modified. So the address, the caller of the function wants to donate to gets the value of the message added to its credit. Then there's this function to query credit. So the argument is again an address and the function simply returns the value of this mapping for this given address. Finally, somebody that does have credit is allowed to withdraw some of the credit. So he specifies the amount. Then first it is checked that the sender, the caller of this function has actually more credit than he wants to withdraw. So that his credit is greater or equal than the amount. Then this is the crucial line that as we will see exhibits the security flow. Then the sender of the message is called and its fallback function is called with the value of the specified amount. So in this line, the simple DAO contract transfers the specified amount to the caller of this function. And finally the state, the credit is updated. So the amount is subtracted from the credit of the sender. So that looks innocent enough. Let's first deploy it on the Ethereum testnet and see how it's supposed to work. So in the remix IDE, I am connected to the Robson testnet for the Ethereum network. And I have an account that has some test ether on it. So I check whether this compiles, I get some warnings but I ignore them and just deploy. So now MetaMask asked me for confirmation because I have to pay some gas. So let's see. Now we have to wait until the contract is deployed. Okay, the contract has been deployed and it's accessible now here in remix. And I can test its functions to donate the withdrawal and the query credit function. To test it, I need another address that I can donate to. So in MetaMask, I have a couple of addresses. So let's just select the second one and copy the second address to the clipboard. Reselect the first one and now from the first one, I donate to the second one that I copied. And let's say I donate 0.1 ether. Let's do that. Must confirm. And let me check whether the donation arrived. So if I put the same address there, then I see that indeed there's a credit now for this address. Now for the fun part, let's see how the attack works. So I'll assume a different identity in remix. I'll choose another one of the Robson test accounts I created. And the first step will be to deploy this devious smart contract that I called Mallory. So it imports the simple DAO that we looked at earlier. And it references the instance of the contract that we just deployed. So I looked up the contract address and added it here. So this variable will refer to that instance of the contract that we deployed. Then we have this owner variable. In the constructor, we just set the owner to the account that creates this contract. Then the really devious function is the fallback function which checks the credit it has at the DAO. This contract, the credit that this contract has and then calls DAO withdrawal with that amount. So if we remember what will happen, DAO withdrawal will check whether the requested amount is less than or equal to the available credit. In this case, it will be equal. So this succeeds. Then the fallback function of the caller will be called and the requested amount will be transferred. So we end up calling this function again. And again, the credit hasn't diminished because we haven't reached this line yet. So the fallback function will again call DAO withdrawal with the same amount. The check will again succeed and again funds will be transferred. And this will go on and on until we either run out of gas or until the DAO is drained. So in remix, I deploy this contract. So after having deployed the contract, I must donate some money to it. Because remember in each loop, I will withdraw the credit I have. So there must be some credit so that there are not too many loops and I don't run out of gas too early. Ideally only after the DAO has been drained. So let's donate 0.05 Ether to the Mallory contract. Let's check that it got some credit. Okay. And now I can start the attack. So I call the fallback back function. And before I do that, just note that the account now holds 0.94 Ether. But that is after I donated 0.05 Ether to Mallory. So I should get that back plus drain the DAO of the other donations. So if everything went well, then the DAO has been drained and all the money transferred to the Mallory contract. So finally for me to get my hands on it, I must call this get jackpot function, which simply transfers all the money out of the Mallory account to the owner, which is the creator of the contract, which is myself. So let's do that. Okay. And now let's see whether the balance has updated. Yes. Now it updated. So we see now we have almost 1.1 Ether. And before the attack we had and before donating to Mallory, we had 0.99. So we really drained the DAO of the 0.1 that was donated earlier by some honest person. So we successfully pulled it off and the attack worked. So now let's try and see what happens if I try the exact same attack in Yelle. For that I'm using the remix clone for the Yelle testnet and I copy paste the exact same simple DAO code and try to compile and I get an error in line 17. Low level calls are not supported in Yelle. So this suspicious call, the crucial flaw in the DAO contract is not even allowed in Yelle. I mean Yelle doesn't support these low level calls. And so what we actually want to do, I mean the intention of this line was to transfer amount to the sender of the message. So let's, in order to fix this compiler error, we can of course do that directly. So message sender transfer amount, okay. And the error should disappear, hopefully. Yes, it does. So what's the difference? Why is that better? And the point is that the transfer function or command has a fixed gas amount of 2,300 gas. And that is enough to transfer money to pay for the transfer, but it is not enough for a function call. Remember in the malicious Mallory contract when money was deposited, so the fallback function was invoked. The fallback function did was call into the DAO again and call again the withdrawal function. But this call needs something like at least 9,000 gas. So the gas provided by this transfer function is simply not enough. So that simply won't work. And to be honest, in principle, you could, if you really wanted to circumvent that, not from Solidity, but if you did the similar contract in Yelle directly, you could actually specify a higher amount of gas here. But that's exactly the point. You would have to explicitly do that. And I mean the creators of the original DAO, of course, didn't want to provide so much gas. They just didn't think about it or didn't realize that they opened themselves to a fatal attack by doing that. So by forbidding these low level calls, Yelle forces you to think about what you're doing and it stops you from doing this mistake. So once we have replaced this low level call by the transfer function, it does compile. So let's deploy the contract. I must enter the password for this account. Confirm. And it's deployed. Now I can try to donate some money. So let's donate to this one. Just copy this and choose the first one again. Okay, so I donate to this address. Specify a value. Now for this account, I actually don't have so many funds. So I can't choose as high a value as I did in the previous example. So let's use 003 Ether and donate. Confirm. Okay. Now let's switch to the identity of the attacker and I just copy paste the memory code. Actually, I did that before. So let's just load that. Okay, I must just change this address to the address where we just deployed the Dow to. Let's do that. Okay. So this is the exact same code that I used before for the attack. Let's see it also compiles. Yes. So there's no problem with this. So let's deploy that in password for this account. Confirm. Okay. Melody has been deployed. Now I donate something to the Melody contract as before. So let's also take one, for example, Ether. Okay. Let's see whether this worked. Yes. And now let's try the attack. So remember earlier from the honest account, I donated 003. So if I pull off the attack here, I would get above 03. So let's see what happens if I call the fallback function and we see that nothing happens. So the call is just not successful. And that is because it the transfer function will throw an exception because it will run out of gas. So here in the line we had to change when this is tried, then as I pointed out, there's a limit of 2300 gas. It is simply not sufficient because this callback into withdraw would take 9000 gas. So that means the transfer simply fails and throws an exception. So nothing happens and the transaction is not accepted. So we can't steal the money that way as we did in the EVM. So in this example, we have seen how the DAO is simply not possible in Yelle. And the reason was that the designers of Yelle decided that low level calls were security risk and simply didn't enable them in Yelle. And that's only one of the differences between the EVM and Yelle. So if you want to learn more, you should check out the Yelle homepage on GitHub at front-time verification Yelle semantics. And in particular there is this document design.md and that contains a lot of details and explanations about the differences. So in particular about the jumps and the low level calls that are not allowed and so on. So please check that out if you want to learn more. So in summary, we have seen a very simple version of the DAO and tried to understand how it worked and walked through it on the Ethereum testnet and managed to successfully reproduce it. And then we saw that the same is simply not possible on the Yelle testnet due to the improved design of Yelle with security in mind.