Stefan Tilkov: Welcome, listeners, to a new episode of The CaSE Podcast, another conversation about software engineering. This episode continues my conversation with Bitcoin expert Andreas Antonopoulos about Bitcoin, Ethereum, and other blockchain topics. Enjoy!
Stefan Tilkov: One of the things that I encounter a lot of times at the moment is that people are excited about the blockchain, but not about Bitcoin. It's kind of the enterprise view of things; we want to invest in the blockchain, but Bitcoin is just a failed experiment, it's just something for geeks and people who are not really in the industry. What's your view on this? What is the difference between the blockchain and Bitcoin, and why would Bitcoin play a role opposed to all of those maybe 1,000 startups that also do something based on the blockchain, which is obviously much more reasonable than what Bitcoin does?
A. Antonopoulos: I think we heard this argument a lot more in 2014. It's beginning to wane a bit, because more and more people are beginning to understand better what this technology is. It's very similar to saying, like in the early '90s, "Yeah, I like this idea of TCP/IP or an inter-network, but I can do a better job with a different protocol, and if we don't do it on the public internet, which is full of weird people who can connect without us knowing who they are, but instead we do it on a closed network..." - that's what birthed CompuServe and AOL and other gardens, and it also birthed a series of corporate internets.
A. Antonopoulos: In the end, the internet proved that the most interesting innovation was happening on the open public internet, and the value of a simple protocol layer that had innovation at the edge and was decentralized and neutral to traffic, was far more effective than other protocols. There was a lot of competition in the early days between ATM, the OSI stack and TCP/IP. And people said "Well, TCP/IP will never succeed, it's too simple. It doesn't have enough quality of service guarantees, it doesn't do prioritization, it doesn't do filtering, it doesn't do all of these other things." It turns out those things were what was keeping TCP/IP open and allowing people to innovate to the edge.
A. Antonopoulos: The whole point of Bitcoin is the open decentralized, borderless, censorship-resistant, neutral, interconnected and peer-to-peer capability. That's the unique thing. The blockchain is a distributed database which doesn't scale particularly well. If done properly, for that lack of scalability you get the benefits of decentralization. But in order to do that, it has to be open, it has to be public, and it has to be participatory, just like the open internet. That's where it gets interesting. That doesn't mean Bitcoin is the only one.
A. Antonopoulos: I'm not a Bitcoin maximalist, and I will tell you that any of the open public blockchains can create environments that are decentralized, neutral, censorship-resistant and try to do that in different application areas. It creates a very interesting effect. But what you hear most of the corporates talking about, these enterprise blockchains, they're not talking about open, public, decentralized, neutral, censorship-resistant; they're talking about closed, centralized, controlled, censored, non-neutral systems. Those take all of the disadvantages of the scalability to achieve nothing in return. They create the intranet of money. They're going to be useful for some narrow cases, but for the most part, that type of closed, centralized blockchain is just boring. It's as boring as the Frontpage, Outlook, Microsoft, Intranet and Oracle database you have inside your accounting department at a large corporation; none of the exciting innovation of the internet is happening there. In fact, nothing exciting ever happens there, by design.
Stefan Tilkov: Let me try to play the devil's advocate, or the banker's advocate here, and argue that the thing that inhibits scalability and the thing that creates the most problems with Bitcoin and the other public blockchains is the reliance on proof of work, which I understand why it has to happen... But if I have a group of people that I trust a little bit more, like my peer group of other banks or financial institutions that I have contracts with, then I can simply use a good old private-public key cryptography and base my blockchain on the assumption that I trust the partners at least to a certain degree. Is that a completely invalid argument, or do you buy parts of it?
A. Antonopoulos: It's not invalid, it's just that in practice it doesn't really address most of the interesting things that Bitcoin is attempting to solve. We live in a world where billions of people are completely excluded from economic participation because they do not have adequate documentation or political power to be granted access to a vetted system of finance, and Bitcoin attempts to solve that by giving up on the 'vetted' entirely, and making an open system.
A. Antonopoulos: If you have these third-parties, you have to trust these third-parties, and these third-parties have proven to be, historically, very not worthy of trust, because the power to control money is a power that corrupts very quickly, and when it comes to deciding on how to protect themselves or your investments or your money, they will protect themselves every time, at your expense.
A. Antonopoulos: Now, to get a gang of these -- what's the correct word...? Right, a cartel of these bankers to coordinate on a federated system where they decide how to fix the blockchain every ten minutes based on their third-party fully-trusted signature - well, they don't even trust each other, so they're gonna have to overcome that problem. It's the same idea with trying to make the internet a closed system of protocols that gets agreed completely by the telecommunications companies. Now, if you remember your history, they did actually try to do that; that's what OSI was, and ISDN, and they failed. The reason they failed was because as they were trying to design standards, everybody was jockeying for a position, patenting stuff behind closed doors and trying to gain an advantage on their competitors. They never managed to do federated standards, because closed federated committee standards fail because of that type of competitive, collusion, cartel(ish) behavior.
A. Antonopoulos: The idea that the banks will do that... They've tried. They've tried numerous times, so one, I don't think that they're going to succeed. They're going to succumb to all of the problems of scaling and incentive competition within committees as to how they build these things. Now, let's say they even did achieve that. Well, they've built this blockchain - great. Now, they're bound by jurisdiction regulation and law, which means they have to vet every participant. If they have to vet every participant, then they're going to continue to exclude billions of people who they can't or don't want to vet, which means the system will not be borderless, and it will not be open. It will be bound to very narrow jurisdictions, just like the existing system. It will require you to trust the same institutional third-parties, it will be non-neutral, it will require censorship and control of endpoints and vetting of endpoints. It will allow money laundering only by the banks, who will get away with it just like before, and they'll require bailouts every now and then, only these will be called "blockchain rewrites" where they have to go back and rewrite the transactions to make it appear like they're still solvent. So it doesn't actually solve any problems.
A. Antonopoulos: It's a bit more efficient maybe than the centralized databases they use today, but it removes the third-party clearing house, which now has been an independent third-party, and replaces it with a cartel of interested parties which are the federated bankers. So there's all kinds of problems with this scenario, and I expect that it's going to grind itself out in bureaucracy for many years, for the same reason that the telecoms were never able to build a competitor to TCP/IP, for the same reason that healthcare companies can't get their act together on medical records. These just end up being terrible ways to design software.
A. Antonopoulos: Meanwhile, on the Bitcoin side we've still got an open, borderless, all-inclusive, open access network that is neutral, and it uses proof of work not just as a gimmick... It uses proof of work to replace proof of institution, to replace institutionalized power and hierarchical bureaucratic power with an open, flat network system. That's not a bug. It's a bug if you're an institution who is threatened by that. It's a feature if you understand the internet. So it will remain incomprehensible to bankers, who see trust as an emergent property of institutions, rather than possibly an emergent property of a flat collaborating network of peers. Bitcoin proves that you can also build trust that way, and yes, if I was a banker, I'd be terrified by that idea.
Stefan Tilkov: Okay. So maybe let's talk about one of the major alternatives to Bitcoin in terms of being open and publicly accessible and open to everyone, which is the Ethereum blockchain. Can you briefly explain how it's different from Bitcoin?
A. Antonopoulos: Yes. Quick disclaimer before we go any further is my next book, which is an O'Reilly book as well (like Mastering Bitcoin), it's called Mastering Ethereum, and I'm writing it with one of the two founders of Ethereum, Dr. Gavin Wood. I've been interested in Ethereum since I received a copy of the whitepaper before it was even published, and had a look at it and talked to the other founder, Vitalik Buterin; I tried to understand better what the system was doing. What Ethereum is is a blockchain that's not used primarily for currency, but instead for running small programs. So it's a programmable blockchain where what you store is not transactions, but programs; these programs then are executed simultaneously by everyone who's validating their execution.
A. Antonopoulos: These are Turing complete programs that take transactions as inputs. Then as the program executes, it modifies state; that state is recorded as a state transition in a ledger. So instead of with Bitcoin where the transaction records a transition of ownership of funds, in Ethereum the transaction is simply input. It's fed into a program which is itself on the blockchain, and then the state transition of that program - all of its variables and how they change - is recorded in compressed format as the outcome of that transaction. So it's a fully Turing complete state transition engine which uses a virtual machine to execute bytecode in a completely decentralized manner.
A. Antonopoulos: It's fascinating, and I think eventually we'll find some very interesting applications. I don't think most of the applications we see today are that interesting, except for one or two. It's been used a lot to do crowdfunding-type things - what's called ICO's, which are basically crowdfunding launches where people create a token which represents either equity or access or some kind of product or service, and then they sell that token, raise money and use it to finance a new venture. That's kind of interesting. Most of the things that are ICO-ing right now are garbage and will never return an investment, but that's not a criticism of the underlying technology or the potential of this kind of global open crowdfunding. I think that's amazing, it's just that the people who are using it today are not doing amazing things with it, if you see what I mean. It's important to make that distinction. I think the technology is amazing, I think it will have enormous implications with crowdfunding, I'm just not particularly interested in any of the attempts made so far.
Stefan Tilkov: Let me try to get back to understanding what it actually is that you just explained to us. You said that it's programs that are being run by the blockchain. Does that mean that the Ethereum blockchain is one giant virtual computer running serially one program instruction after the other? The thing I'm trying to wrap my head around is that in the Bitcoin blockchain validating a block is being done by the miner, and then that block is being put onto the network, and then it becomes part of the blockchain. What you've just described, it seems to me that the block that's being mined includes the result of all the processing of the things, but in essence, essentially it turns into a history of all the computations that occur, and that essentially means that the whole computer has to run everything that anybody ever puts on this thing as a program.
A. Antonopoulos: Yes.
Stefan Tilkov: How is that ever going to scale?
A. Antonopoulos: So everybody who validates an Ethereum transaction, in order to validate it has to within the EVM sandbox run the program that it's addressing and evaluate its state transition and compare that to everybody else until they achieve consensus as to how that state has transitioned. A good way to think about it, if you're familiar with database technology, is the concept of journaling, the concept of atomic transactions within a journal, the concept of stored procedures, and the concept that if you do a database query and it triggers a sort of procedure, and that causes a transition in the state of the database, which is recorded as a series of journal entries, and then when you commit those journal entries you transition the state of the database permanently. And the fact that you can replicate that among multiple computers that are all kind of in-process, adding to the journal and then eventually achieve consistency in their database by processing those journal entries in the same way. In a way, it's very similar to that, with the addition of a lot of cryptographic primitives and things like that.
A. Antonopoulos: But yes, how does it scale? Well, I don't know. That's a very interesting question. Again, the answer is "not all in one layer." So if you think Bitcoin scales poorly, Ethereum scales much more poorly, for the obvious reason that it has to do a lot more. But that also means that the things it's doing are quite a bit more valuable, because the introduction of a Turing complete programming language means that - or Turing complete execution environment rather I should say - it can do more interesting things. In fact, it can do an infinite variety of interesting things, all of which will need to be stored on the blockchain.
A. Antonopoulos: There are a number of ways to scale that. The two main forms are partitioning, also known in Ethereum parlance as "sharding." Partitioning is just as with database sharding - it's where you store a partial replica, not a full replica, and each database cluster is responsible for computing just one partial replica, and the entire thing is kind of an emergent collage of all of these replicas... Which means that not all contracts are stored on all nodes; some of these Ethereum programs are stored on some nodes, they're calculated and validated by some nodes and not all nodes, and that there isn't a one global copy. There's lots of little local copies which collaborate to create an emergent global state. Not quite clear yet how that will work, how you scale that, how you make it decentralized, how you achieve consensus across these sharded partial replicas, but that's the direction it's going.
A. Antonopoulos: The other one is just like with Bitcoin, it's doing a lot of the computation and state transitions off-chain, and then only aggregating and check-pointing a summary of that in the base layer. So you have a second layer on top. And again, that's scaling out, or scaling in layers.
Stefan Tilkov: Can you very briefly talk about the way Ethereum is programmed? Does it have its own programming language?
A. Antonopoulos: Yes, sure.
Stefan Tilkov: How do you go about that?
A. Antonopoulos: At a very basic level it has a virtual machine. The virtual machine is a well-defined -- in fact, it's defined in a paper that defines it in mathematical terms called The Yellow Paper. The Ethereum Virtual Machine is a bit like the Java Virtual Machine - in fact, a lot like the Java Virtual Machine - in that it executes bytecode, which is a form of Assembly language. It does so with the addition of an accounting mechanism, and the accounting mechanism counts how much processing you've done and deducts that from an Ether account. So in Ethereum, the currency (which is called Ether) is not used to do financial interactions as much as it is used to fuel and meter and resource constrain the execution of these programs.
A. Antonopoulos: On the principles of computer science, a Turing complete execution environment means that you have the halting problem. The halting problem is that you don't know when it's gonna stop; it might never stop. You could have an infinite loop. So how do you stop a program from consuming the resources of the entire global world's computers as you described it, by simply running forever in a closed loop that does a denial of service? Well, the way you do that is people have to put up Ether, which has monetary cost, and that Ether is consumed by the execution of the program, and puts an upper limit on how much execution is allowed in each program. And there's a global limit for the entire network, which is called a GAS limit, which dynamically adjusts... So in every block you can only do a maximum amount of computation, and in every transaction you can only do a maximum amount of computation. So you can't do denial of service on the network.
Stefan Tilkov: So essentially, a contract and a program are the same thing on this particular blockchain?
A. Antonopoulos: Yes, we use the term smart contracts which we use for a program that is neither a contract nor smart. The problem is that the real practical meaning of the word smart contract is a dumb program. It's basically the program written in Solidity. There's nothing smart about it, and it's not really a contract. Those terms are a legacy of some previous work that was done in this space and people thought it sounded fancy, but I think it just confuses the hell out of everyone.
Stefan Tilkov: Does Bitcoin have a programming language?
A. Antonopoulos: Bitcoin dies, yes. Every transaction you do in Bitcoin is actually the invocation of a script, and the script is written in a Forth-like Reverse Polish notation stack-based language, which to anyone who is I guess younger than 40 means absolutely nothing. Forth is a language that was obsolete even before I got into computing in the early '80s. It's a very simplified script language that involves an execution stack, stack meaning a data structure where you push and pop things only from the top of the stack, so it's a last in, first out queue system. It's a sort of functional language where you pass the parameters, put them on the stack, and then you execute an operator on those parameters and it pops them and puts a value back onto the stack. It looks weird to most people.
A. Antonopoulos: The reason it's done that way is because 1) this is not Turing complete; you can't actually write arbitrary programs, its execution is predictable, you can deterministically analyze exactly how the program is going to behave, how many operations it's going to consume, and you can figure out how it will halt and when it will halt, because you can analyze it statically and formally before you execute it. It's also quite constrained, which has a number of security benefits. It's very simple in nature, it's very hard to introduce a bug in that language. But of course, you can't do a lot of fancy things.
A. Antonopoulos: The primary differentiator - Bitcoin is designed to be very robust, very simple in its scripting language. You can do a lot of interesting things like multi-signatures, payment channels and some basic smart contract functionality, but you can do them very securely if you accept those limitations. With Ethereum you can do everything, except doing it securely is very difficult, as has been demonstrated over the last two years. So it's going to have a bigger exposure surface and a longer maturity curve. It's going to get there for sure, but perhaps for now, for very secure, focused, robust applications involving money, you have to choose the tool that's right for the job. And in some ways it's a bit like comparing Assembly language and React.js. For some things, you want Assembly.
Stefan Tilkov: Okay. So this obviously addresses one of the key concerns that many people have with Ethereum, which is "How are we going to make sure that the smart contracts or dumb programs we send our virtual money to can actually be trusted with it?" How can I ensure that I'm not going to run into some intentional or unintentional bug in the program that I'm interacting with? Both as a user of that program, who talks to it, who sends money to it, as well as a programmer trying to come up with a great contract.
A. Antonopoulos: Unfortunately, the simple answer is that in order for that maturity and trust to develop you need time, and a lot of experimentation, so that once a piece of code has been used for a long, long period of time, with money and increasingly more and more and more money sitting in there and remaining secure, you can say "Okay, well it seems to be remaining secure." It's a pretty big honeypot; if there was an obvious bug, someone would have grabbed it by now, so that gives me some confidence. And then you iterate with more money, more stakes and better audits of the code, until you can build slightly more complex and sophisticated applications.
A. Antonopoulos: At first, the only things you can do are very simple things. In security there's no such thing as secure or not secure; it's not a bullion. It's a risk/reward equation, and you have to say "How much money am I willing to risk, and what is the reward for an attacker, and where is the balance where the reward for the attacker isn't sufficient to cover the cost of the attack, and my risk?" We can say, for example, that Bitcoin can secure tens of billions of dollars. How can I say that statement? Well, it's sitting there and it's still there, and for the most part, other than people stealing the keys, they can't seem to steal it directly off the blockchain, and it's not because they're not trying; they're trying. So I can say with confidence after nine years of people attacking it continuously and failing to break the actual protocol in any meaningful way that it is very secure for that purpose. And I can say that to a lesser extent for some very simple Ethereum contracts, but the only way to prove that is to simply continue to increase the stakes and continue to refine and mature the code, and keeping it simple at first is important.
Stefan Tilkov: Okay. One of the things that I found intriguing about Ethereum was that very early on some of the whitepapers and some of the blog posts talked about one day switching from proof of work to a proof of stake mechanism, a term that you've mentioned before. Can you walk us through what that means and what some of the advantages and downsides of it are?
A. Antonopoulos: Well, that is not just a plan, it's imminent, and in fact there is a built-in mechanism to accelerate that process called the difficulty bomb, which is a really unique and interesting twist in Ethereum. In Ethereum, the mining gets more and more difficult over time, until eventually the difficulty increases so rapidly that it becomes unprofitable to mine, and this is to force the mining to have an expiration date. It's like a sunset thing; the mining cannot continue indefinitely. It has within it a mechanism that will dismantle it.
A. Antonopoulos: The mechanism to replace it, based on this motivation to replace it - because it will be dismantled automatically - is called proof of stake, and the mechanism for proof of stake for Ethereum right now is codenamed Casper, as in Casper the ghost, if you're familiar with that particular part of American cartoon culture. Casper is a proof of stake implementation that is I guess in pre-production and undergoing significant testing right now and refinement. It is a proof of stake system whereby consensus is achieved by locking up an amount of Ethereum into a program or a smart contract that validates the next block. And if that block is accepted and remains part of the blockchain history after a certain number of blocks - perhaps hundreds of blocks into the future - you can recover your initial investment. If you commit that money in the form of Ether and you don't validate correctly, then you lose some of that money.
A. Antonopoulos: Instead of having an external source of energy that you prove through computation, instead you basically put down the intrinsic currency of the blockchain as your assurance bond or stake, and then you validate and sign the blocks. And if you validate and sign them correctly, you get a small reward that is added to your initial stake and given back to you. If you fail to validate correctly and your block is rejected, you lose some of your principal. So it's simulating the same kind of risk/reward competition as proof of work, only without using any external energy. It's only using the internal funds of the system.
Stefan Tilkov: That actually sounds pretty awesome. What are some of the downsides?
A. Antonopoulos: Well, it's fascinating, it's awesome, and if it works, it's going to be a very interesting way of doing this. There's a couple of downsides. One is that when what you're staking is intrinsic to the system, there's two parts to this risk/reward or game theory, at least in my mind, which is that if in manipulating the system you end up increasing the value of the currency or decreasing the value of the currency, that may override the actual value of what you staked. The problem is the thing that you're guaranteeing is also the thing that you're manipulating... Whereas when the thing you're putting down as a guarantee is energy outside of the system, you can't change that. if the thing that you're guaranteeing is the currency inside the system and what you're securing is the currency inside the system, there are certain scenarios where you could gain both ends of that. There are some advantages to having an extrinsic source.
A. Antonopoulos: The other issue is that, in my mind at least, the cost of rewriting the past is measured in Ether, and if you rewrite the past so as to give yourself more Ether, and you previously staked Ether, then again, I'm not quite sure that you can make the same immutability guarantees. Here's the good news however. If you already have an immutable blockchain that uses proof of work, you can actually checkpoint the results of your proof of stake blockchain in the proof of work blockchain, and essentially buy immutability for the cost of a transaction, which means that many of the more powerful models I think come out of this are hybrid systems where you either have proof of work and proof of stake in one - which is the transition plan for Ethereum - or eventually you have proof of stake in one blockchain, but it's also secured by checkpointing in a proof of work blockchain that becomes the one immutable ledger that supports all of the others... Which isn't a bad place for Bitcoin to play, as well.
A. Antonopoulos: I think these are all fascinating. Of course, we haven't done proof of stake at that scale ever before, no one's done it; we don't know what happens. All of the theory goes out the window when you put 50-60 billion dollars in the middle of the table and say "Trust me, this is secure. I've worked out an algorithm", and that algorithm will be tested in a very public and possibly very humiliating way if you get it wrong. It's an experiment worth running, and in many ways we have to accept that the only way to run this experiment is with real money on the table, in real-life circumstances, because you can't predict the ingenuity of an attacker. You can only defend against it in real time. And the ingenuity of an attacker, from a security experience, is always greater than you can imagine. So the only way to test that is to put a big enough reward in the middle of the table to engage the most ingenious of attackers. If they fail, then you can say something about the security of your system. And that's a moving proposition. In Bitcoin we've already done it to a certain extent, now we'll see whether proof of stake can also do it to a certain extent.
Stefan Tilkov: One idea that you've mentioned multiple times is this idea of securing or check-pointing parts of an off-chain transaction within, for example, Bitcoin. How would you go about that? Let's say I build a system that's built using traditional centralized infrastructure, or some other less trusted blockchain or a similar mechanism... How would I go about check-pointing stuff within, for example, Bitcoin?
A. Antonopoulos: There's a number of different techniques or technologies that you can use at a very basic, fundamental level. Let's say I want to take a fact that exists today. For example, let's say that I've just graduated from the university and I've received a certificate, and I want that certificate to be recorded in such a way that everybody know that on or before this date of 4th December or whatever, I had received this certificate. That kind of time-stamping is fairly easy to do, as long as you have some form of recording that is immutable. A classic way of doing that is to get in front of the video camera, hold up a copy of today's newspaper and say "Here, I have my certificate in one hand, I have today's newspaper in the other, you can ascertain from this video that on this date (or before this date) I had this paper."
A. Antonopoulos: On the blockchain, the way we would do that is we would take, say, a PDF of a university certificate and we would compute a cryptographic hash - SHA-256 would be the most convenient - and then we would take that cryptographic hash and we would attach it to a Bitcoin transaction using a data script operant, which is called OP_RETURN. Basically, what that means is there is space in the Bitcoin transaction where part of your scripting language you can simply say "Store this value" and give it a 32-byte value. So we take the cryptographic hash, we put it in the transaction, we digitally sign the transaction, we transmit it to the blockchain, the Bitcoin network, and it gets mined, and it gets added to a block. Once it gets added to a block, that hash is in the transaction. The transaction hash is in a tree of hashes that is in the block, and the root of that tree, that hash, is part of the thing that was secured as proof of work, and that then informs the hash that is recorded in the next block, and which is recorded in the next block, and the next block, and the next block, in a chain, which is why we call it a blockchain.
A. Antonopoulos: So you can cryptographically prove by looking at a block today that 6,000 blocks before this other block was its parent, because there's an unbroken chain of cryptographic hashes, that in the meantime an enormous amount of energy was expanded in order to record all of this information, which you can see from the proof of work, that in that block there was a series of transactions; you can prove the existence of that transaction at that time, because the hashes all add up to the header of the block, and within that transaction is the hash of my university certificate that must have existed at that point of time for me to calculate the hash. And boom, I've checkpointed it in time, and I can offer a compact proof which is a log2n-sized proof of hashes that shows my inclusion of that certificate in that specific block. Anyone with access to the blockchain can then validate that for themselves without appeal to any external authority, and validate conclusively, and in fact validate that that blockchain could not even have been rewritten, because the amount of energy that it takes to rewrite that would be ludicrous.
Stefan Tilkov: Okay, and obviously I would address the problem of this being somewhat expensive, depending on how much worth I attach to that certificate, by just doing that for a batch of certificates, like checkpointing 100 certificates at one time.
A. Antonopoulos: The way it works is that you can very simply, by encoding a single hash per block, you could in that hash summarize a billion certificates with a tree just 20 levels deep; using that binary lookup algorithm you can still produce a compact proof of 20 hashes to get a billion certificates in there, and produce -- well, with 32 levels deep you can do four billion certificates, right? And yet, all your storing in the blockchain is one hash, and that can summarize billions and billions of documents. So it's a very scalable mechanism for doing that. Even though it's expensive to do one, it's no more expensive to do a billion.
Stefan Tilkov: Okay. Assuming that's the case - let me play devil's advocate again... Let's say I accept that Bitcoin has been proven to work and is available and is something that I can use for exactly that purpose, why do I need something like Ethereum? If I can build anything off-chain in the classical centralized way, I can get the trust that I want by simply securing the stuff in Bitcoin, why do I need anything else?
A. Antonopoulos: That's the first question I asked Vitalik Buterin when I read his paper. And the answer is really quite -- well, not to pat myself on the back, but I think it's an insightful question which comes to the roof of the matter, "Why do you need a separate blockchain to do that? Why not build it as a layer on top of Bitcoin?" and the answer that Vitalik gave me at the time, which was extremely persuasive and it's the reason I'm interested in this, is really simple - because what the Ethereum blockchain is doing is it's validating the execution of the program itself as part of the consensus rules, which means that the security model that is supporting the underlying mechanism is not simply just checkpointing the state, but it is also validating the correct execution of the program.
A. Antonopoulos: Unless you have lots of people validating the correct execution of the program, you can't really have any guarantees for that program, other than its final state. And you can't just checkpoint the final state at the cost of a single transaction without that going back to what I was talking about before, which is you get something for nothing. If all I've spent is $25 in order to validate that a hash existed at a specific time--
Stefan Tilkov: Then it's worth $25. It makes a lot of sense.
A. Antonopoulos: Exactly. You need bigger stakes, so if what you're validating is in fact the complete and comprehensive execution of that program, and it states transition as part of the consensus rules, and to do that you're putting a stake in either external energy with proof of work, or intrinsic currency with proof of stake, that means you have a lot to lose if you don't do it correctly, and that provides the security. So what you're getting is guaranteed execution and correct execution of this program in an unstoppable, uncensorable way across the world's computer, and that is a very valuable thing, I think, for certain classes of problems certainly. That is completely distinct from what Bitcoin is trying to do.
Stefan Tilkov: I agree. To take our example, with a certificate, I could be checkpointing the hash of a certificate from Trump University. It's kind of true that I'm validating that I have this certificate, it just doesn't mean very much, so validating--
A. Antonopoulos: Let me give you another example, which is the concept of proof of publication that often trumps a lot of people (no pun intended)... Which is let's say I was making stock predictions, and I'm gonna say "Okay, I'm gonna predict the price of Apple every day for 30 days..."
Stefan Tilkov: Or of Bitcoin.
A. Antonopoulos: Yes. And then I'm going to prove to you what an amazing financial analyst I am by publishing all of my predictions after I checkpointed them. So what I do is I do a yes/no or the amount I think the Apple stock will be today - I take that, I hash it, I put it on the Bitcoin blockchain. I then take tomorrow's price, I hash it etc., and I do that always a day in advance, so you can see it's the day before for the day after, right? Then at the end of the month I publish all of these hashes, I publish all of the proofs, I show you that they were checkpointed in advance, and I have a prediction rate of 95%, and you say "Wow, that's amazing!" The problem is I didn't actually prove anything, because I could have actually been recording 100 proofs a day, at 100 different price points, and only publish the ones that were closest.
A. Antonopoulos: Now, if you think that's a far-fetched thing, someone's already done this on Twitter. And what they'll do - and I'm kidding you not - is they'll Tweet price predictions; they'll tweet 1,000 price predictions a day. They'll do that for a month, and then they'll go back and using a script they'll delete all of the ones that are wrong, and then they'll use the Twitter record to say "Look, I was tweeting out all of these correct predictions for a month", and naive people will look at that and go "Oh, my god. This person - it's like they have the crystal ball." They've removed the erroneous predictions and only selectively presented (selection bias) the correct ones.
A. Antonopoulos: So checkpoint doesn't tell you that no other things were checkpointed, or that that was the only one. It only tells you that at least that was checkpointed at that time.
Stefan Tilkov: Well, as Bitcoin is immutable, you wouldn't delete stuff, you just wouldn't tell anybody that it's there, right?
A. Antonopoulos: Which is equivalent...
Stefan Tilkov: I agree.
A. Antonopoulos: If it's included in a Merkle tree, it's impossible to know how many branches that tree has and how many of them you haven't revealed. You can only see the things that people show you, which is a feature, unless you use it in that way. Now, compare that to running a smart contract that records as part of its output log, the state transition of every prediction you've made... Now, in that case, you have each of the data points validated separately, not just their hash. So you could do proof of publication with a smart contract that you can't do with simple time-stamping and checkpointing.
A. Antonopoulos: So there are a whole class of problems that Bitcoin is not flexible enough to solve, but there is a tradeoff. The tradeoff is that in order to do that, you have to have a Turing complete language, which creates a larger security exposure surface and much more complexity, and that complexity makes the system a bit less robust and slower to mature. That doesn't mean you can't do it, it just means it's suitable for different purposes.
A. Antonopoulos: One of the talks I've given in the past which I think captures this analogy quite well is I call the two systems the lion and the shark. The Bitcoin maximalists will say "Oh, the lion is the chief predator, the apex predator", and the Ethereum people will say "No, no, it's the shark! It's clearly the shark!" So if you have this hypothetical scenario, you say "Okay, let's do a cage match. Let's put them in a cage and have them fight each other." The only determinant characteristic that will decide the fight is whether the cage is underwater or on land. The bravest of sharks will be sushi on land, and the fiercest of lions will be shark bait in water because every single adaptation that makes them the apex predator in one environment excludes them from being the Apex predator in the other. The road you travel takes you away from the road you didn't travel. There are tradeoffs, and these tradeoffs are not "Let's do a bit of everything." In fact, if you created a hybrid lion-shark, it wouldn't be very good at either.
A. Antonopoulos: The bottom line is that in the cryptocurrency environment and ecosystem we really do see this form of environmental specialization or even speeciezation where each of the blockchains make certain design tradeoffs, and these design tradeoffs make it simultaneously more suitable for some purposes, and less suitable for others. So when people ask "What is the best cryptocurrency?" the answer should be "Best for what?" and a follow-up question, because you can't really answer it in the generic. You can't say "What is the best type of car?" because there is a big difference between a NASCAR race car and an agricultural tractor, and each is equally useless in the other's domain.
Stefan Tilkov: That is a fantastic conclusion to our amazing conversation. I'm really happy - we're running out of time, but I enjoyed every single second of this conversation. Thank you so much for being with us. I think we will have extensive show notes, with a lot of links to talks you've given, and to books and to other resources. Are there any parting words that you want to add?
A. Antonopoulos: Well, for developers who are interested in learning more, all of my work is done under open source licenses. Content is produced under Creative Commons licenses, code has been produced under GPL... This is very much an open source phenomenon, and so is my work within this space. If you are interested in learning more from a development perspective, there's my O'Reilly book Mastering Bitcoin, which is for software engineers and is quite dense is available entirely for free on GitHub, and you can read it. The second edition was published recently and it was developed on GitHub, completely open. Buy it if you want, but you don't have to. You can also mesh it up, share it, use it in your notes for any purpose; it's a CC BY-SA (Attribution-ShareAlike Creative Commons License). I would urge you to take a look at that, and if you read it and you like it - great, leave me a good review. If you read it and you find a mistake, I accept pull requests, because that's what it's all about.
Stefan Tilkov: Perfect. Andreas, thank you so much for being with us, and thanks listeners for listening. Bye-bye!