 Curely also asked, what should be done when things go wrong with smart contracts, i.e. where funds are lost due to coding errors and bugs? This is a really great question. In fact, it is the basis of a giant debate happening, primarily in Ethereum right now, which started with a DAO bug, the decentralized autonomous organization that had a massive bug leading to the loss of $155 million. In the end, the Ethereum community decided to revert that transaction, but in the process of doing that, split the Ethereum community into two, and now there is also Ethereum Classic, which is the part of Ethereum that refused to reverse that transaction. This is likely to keep happening. There is an ongoing debate as to what to do when funds are lost due to coding errors and bugs. On the one hand, people might think that this is a way to protect users, but unfortunately, who gets to make these decisions? When you vest power in someone to make these decisions as to when funds can be reversed, not only does that power become dangerous, but the people who have that power are now liable. What happens when a government asks them to reverse the transaction? They can't say, we can't do it, because they've already done it. These are very dangerous and difficult decisions. The opposing argument is that reversing things that were lost due to coding errors and bugs creates moral hazard. Moral hazard is a particular economic condition where people take more risks than they would otherwise take, because they know that they will get bailed out. We find moral hazard in areas such as insurance, banking, and stock trading. When people know that somebody else will assume the risk, or they think that somebody else will assume the risk, they take on more risk. As a result, that leads to more coding errors and bugs. If you knew that if a smart contract has a bug and you lose money, you would never get it back. Would you be more careful with auditing, selecting, and carefully putting small amounts before you put medium amounts, before you put huge amounts of money on top of a smart contract? Conversely, if you knew that if something went wrong, you'd simply get bailed out, would you be more reckless with the use of smart contracts? This is one of the things that is at the heart of this debate, and it's not resolved. There will be different blockchains that choose different policies as to how to solve this. Simon asks, regarding Ethereum, what if there is a bug in the initial program running on all of these different machines? Is there a way to correct the code in the contract, or is it forever flawed? Simon, you've picked up on something that is a fundamental design consideration when designing smart contracts. Smart contracts are recorded on a blockchain, and they represent a fundamentally different development process. Once you create a smart contract and encode it on a blockchain, its code cannot change. It is immutable. It will forever run that way. This creates quite a problem, because if you have a bug, that means it will be there forever. You cannot modify that contract after it is being created. There are a few ways to get around that. One way to get around that is to essentially create a process... where you can migrate from one contract to another, to another, to another, so that you essentially move all of the data, all of the tokens, all of the owners, all of the information stored within the contract, to a new version of that contract that you deploy on the blockchain, and then you kill the old one. However, this isn't so easy to do either, because if you can migrate all of the data, all of the ownership information, and all of that to a new contract, that means ultimately that the developers who deploy this contract... have to retain control over it, which means it's not very autonomous, and it's not very decentralized. Because you have centralized control, and the developers have to retain that control in order to be able to upgrade it, you have some potential issues there. That also means, of course, that there is a whole other class of bugs that can exist in the upgrade code. Specifically, if you look, for example, at the DAO, which is one of the most famous vulnerabilities in the Ethereum space, the DAO had a bug in the code that was meant to split the DAO, so that people could fork off, potentially upgrade and change the code. So, there's a potential that the code that checks who the owner is, and allows you to upgrade and migrate to a new contract, itself can have bugs, and that's a whole other category of bugs. So, this is one of the problems, not problems, it's one of the differences between developing software in a traditional centralized code-test release and version upgrade mechanism, a classic software development methodology. And the methodology you have to use with smart contracts on a blockchain, where you don't have an opportunity, always, to fix mistakes from the past, or where creating the opportunity to fix mistakes is in itself quite complicated. Camilo says, what is your opinion on smart contract developers as the new gatekeeper-middleman intermediaries? So, I'm going to just paraphrase that a tiny bit. So, the idea here is that in a system like Ethereum that supports smart contracts, but this would equally apply to Rootstock or Cardano, or any of the other smart contract platforms that have a virtual machine. While the consensus rules establish that a smart contract will be executed exactly as written, and you can protect those consensus rules through decentralization, that still allows smart contract developers to write smart contracts that are not decentralized. In fact, one of the questions we'll talk about in a bit addresses that specific issue and how it can be a vulnerability. So, the question was, doesn't that just make smart contract developers the new gatekeepers? Because they can write smart contracts that are not decentralized, they can write smart contracts that give them powers. They can write smart contracts that have a certain set of rules, and those rules are not subject to consensus, only the fact that they will be executed correctly. I think part of the issue here is the idea that just because a system has a set of rules, that doesn't mean that you can't write something, contracts, transactions, whatever, to re-concentrate power in a centralized way. The internet is a decentralized communications protocol, but it does allow the emergence of centralized companies on top of it, which is essentially a function of economics, not a function of the underlying protocol. So, you have a completely open peer-to-peer protocol, and on top of that, people build things like Facebook. Similarly, Bitcoin is a decentralized currency, but that doesn't stop someone from creating a centralized exchange, a custodial exchange, and saying, I'll hold all of your keys, don't worry. Or creating a centralized payment processor that says, I'll receive all the transactions, hold all of the Bitcoin, and give you fiat in return, or have a custodial wallet for users, or all of the other things that we've seen, all of these centralized forces, or more recently, build a centralized exchange-traded fund, which is a custodial Bitcoin fund on behalf of other people. Just because the underlying cryptocurrency is decentralized doesn't mean that people can't build centralized things on top of it. The trick is that people can build centralized and decentralized things, and then hopefully the market gets to choose which ones to use so that they get the things that they want. If what they want is convenience and wealth, they'll choose the centralized things that are going to be more efficient at delivering, at least for the short term, the convenience they want at the expense of privacy. If they understand the principles of decentralization, maybe they'll choose the decentralized application. You can go on the internet and use Facebook if you're an idiot, or you can use something that preserves your privacy and gives you choices and is much more decentralized. You can go on Bitcoin and use a custodial exchange to store all of your money. That's not a very good choice, but you can. The same applies to Ethereum smart contracts. Just because someone writes a smart contract doesn't make you use it. Just because someone has set the rules for their Ethereum-based social media network, or their Ethereum-based decentralized exchange, which isn't quite decentralized, or their Ethereum-based smart contract for loans, doesn't mean you have to use that one. If you use that one, you are making a market choice that says, I want to use the rules that they have created. On the very same Ethereum network, you can choose to use a smart contract that doesn't have backdoor ownership and controls for a centralized entity. You can choose to use a smart contract for social media, for loans, for decentralized exchanges. That is truly decentralized. The choice is yours. Are they gatekeepers? Gatekeepers have to have an advantage over other participants in the economy. Gatekeepers generally have a government license, a regulated monopoly, the ability to control the rules by which people play the game. In decentralized currencies, decentralized smart contracts, decentralized protocols, gatekeepers don't have special powers. They don't have the ability to force a monopoly, to get special access, to get special privileges, to get preferential treatment, to get rent-seeking behavior. If someone writes a shitty smart contract on Ethereum, don't run it. They don't have an advantage over anybody else running a smart contract. The developers of smart contracts are not the new gatekeepers in Middleman, because they don't have any special powers. They have to compete. Their smart contracts have to compete for your choices against all the other smart contracts. People make poor choices, but it is their choice to make. The developers don't have any preferential access to Ethereum. I don't think they are the new middlemen for Ethereum. On a decentralized platform, you can write both centralized and decentralized applications. It is up to the market to choose which ones they want to use. Anita has another question. This is about the Bancor hack and security issues with ERC-20 tokens in general. This is an Ethereum question. Can you please explain what happened during the Bancor hack some days ago? What are ERC tokens and how secure are they? Given the Bancor was not the first smart token issue that was hacked, are there many smart contract hacks to come? Is Ethereum simply put less secure than Bitcoin? To start that explanation, on July 9th, one of the big exchanges that is a decentralized exchange, or claims to be a decentralized exchange in the Ethereum space, called Bancor got hacked and lost somewhere around $23.5 million in a combination of stolen Ether, and the Bancor network token, or BNT, I believe it is called, which was their own token. The way the hack happened was that Bancor was running smart contracts that allowed users to operate a decentralized exchange where they controlled their own money, and were able to exchange it with other people through smart contracts, without an intermediary. However, these smart contracts had a privileged account that allowed Bancor to change things, to restrict transactions, or stop the flow of money, or take money from wallets, from what I understand. I may have this wrong, so bear with me. From what I understand, they had effectively a super user within their smart contract, that allowed them to intervene in the case of a problem. We have seen this kind of formulation before. As I mentioned in an answer to a previous question, smart contracts on a decentralized platform can be written in a centralized manner, or a decentralized manner, and you choose which one to do. The DAO, the DAO, was partially decentralized, but still had some curators. However, those curators didn't have enough power to stop the hack. When it did get hacked, there was no one who could undo that hack, and that is a double-edged sword. If you make it completely decentralized, but there is a problem, then no one can fix that problem. But if you make it a bit centralized, so that someone can fix the problem, sometimes that is the problem. In the case of Bancor, what they did was, I believe, they added a centralized wallet that could control some of the functions of the decentralized exchange, so that they could intervene in the case of a problem. However, when that centralized wallet got compromised, it was able to drain money from the decentralized exchange, something that wouldn't happen if it was truly decentralized or fully decentralized exchange. Bancor said that centralization and decentralization are a spectrum, and you can be decentralized even if you have some centralized functions, and that is absolutely true. However, in this case, the centralized functions were the weak part of the system, as they usually are. If you have a system which has some centralized functions, those are going to be the primary target of attackers. Obviously, they can exert greater control over the decentralized system. In the second part of the question, I need to ask, what are ERC tokens and how secure are they? Given that Bancor was not the first smart token issuer that was hacked, that is a great question. You may have heard this term called ERC, and specifically ERC-20. ERC doesn't mean tokens. ERC is an Ethereum request for comment, and it is a precursor to an EIP, which is an Ethereum Improvement Proposal. Very much like in Bitcoin, where you have Bitcoin Improvement Proposals, or BIPs, Ethereum has EIPs. EIPs and their precursor, which are ERCs, are basically just discussions on standards. Eventually, one of these discussions becomes a standard that is either de facto adopted by the community, or through enough votes becomes an official standard, if you like, of Ethereum. ERC-20 was one proposed standard for how to do a transferable token that can be named and have a specific amount of tokens as its initial supply, and can be issued by an issuer and have a token symbol and all of these things, and can be transferred from owner to owner. A lot of tokens were created with various smart contracts from the very beginning of Ethereum. However, each of the tokens used a slightly different way of doing things because they used its own smart contract. ERC-20 was the first attempt to standardize the interface to the token smart contract, so that if you were an exchange or wallet, you could support any token that followed the ERC interface standard. To do a transfer of a token, you would use the same function with the same parameters. If you wanted to check what the supply or how many decimal digits or what the token name or what the token symbol is, you would use the same functions. For a token to be ERC-20 compatible, it means that it supports the five or six functions and variables of the ERC-20 standard. It is very small, you can read it quite easily, and you can find it online. Once it supports those, that means that any wallet or exchange can interact with that token in a very standard way and use that token. Now, really important point, if something is an ERC-20 token, that is a minimalist description of its function, meaning that as an ERC-20 token, it has at least the five or so variables and functions of the ERC-20 specification and does support those. But it can have other functions in addition to that. A basic ERC token has only that, and that smart contract is actually secure. It has been very well tested. So far, we haven't seen too many significant problems. There are a few conditions under which you can accidentally transfer ERC tokens to a contract that doesn't expect to receive them and have them locked forever in that contract. There is a little problem with some of the ways you do transfers if you are not careful, but the ERC token standard itself at the minimalist level has not been hacked. If you take the ERC-20 token and then add a function that says, and here is the special super owner, and then you add another function that says, and the super owner can do a transfer even if they are not the authorized user of the token, then you have something that is still ERC-20 compatible, but has an element of centralization in it, and that may have a bug in the extra functions you added. Just because something is ERC-20 compatible doesn't mean it is secure. The minimalist specification is, but if you go adding things for every line you add, the number of bugs increases exponentially. How many more smart contracts hacks will happen? Ethereum is a system that evolves its maturity by putting code out there, creating a bounty effectively behind these smart contracts, and then having people find bugs and exploit it. It is a system that is designed to have a lot more iterations in its functionality than Bitcoin, move a lot faster, even if that means breaking some things in the process, and is much more experimental. As a result, it has a lot more security vulnerabilities than Bitcoin. Practically speaking, Ethereum is less secure than Bitcoin. That doesn't mean it is not secure. It just means that you need to be very careful about which contracts you use and which you don't. There are some smart contracts that, at this point, have significant maturity. But what does significant maturity mean in a currency that is three and a half years old? We have to have that in perspective. That would be equivalent to Bitcoin in 2012, and Bitcoin still had some rather significant bugs and weaknesses in 2012. Can Ethereum mature to be very secure, at least in terms of a subset of well-matured, well-used smart contracts that are very useful? I believe it can. Will it take longer than Bitcoin? Yeah, probably. On the whole, there are more things to be worried about in terms of security vulnerabilities in Ethereum, because it has a lot of flexibility. A lot of flexibility is a double-edged sword. It means that you can do very interesting and innovative things with smart contracts, but it also means there is a lot more opportunity for vulnerabilities, mistakes, and security flaws. That is an engineering trade-off. You decide, do I want more flexibility if it means less security and robustness in the short term, or do I want less flexibility and have much more security and robustness? Bitcoin answered that engineering trade-off one way. Ethereum is answering that engineering trade-off another way. We are going to see how it plays out.