The first thing to look at, though, is what are the different routes to block chain integration. So, a lot of different routes to block chain integration have been proposed. And in the Bitcoin community, you'll find people who are quite partial to one way or another. So, let's look at four different avenues. And let's get a quick look at what some of the advantages and disadvantages of these routes are. The first one, sort of the obvious default one, is to directly use the Bitcoin block chain itself. And this is the one that we saw in the smart property example as we walked through the steps. The advantage, of course, is that it's easy to deploy. The block chain is here, it has all this miner power behind it, so we know that it's something that's very secure. The consensus process can not be easily disrupted. On the other hand, even though we were able to use some hacks in this example to achieve representation in atomicity, it's not always the case. There's no fundamental reason to believe that if you have some arbitrarily complex contract between different parties that it can be represented adequately on the block chain and that you can execute it atomically. So, to get a better idea of what this might look like, and what some of the challenges to atomicity and representation are, let's look at a couple more examples in how you might try to decentralize them directly on the block chain. So the next one we'll look at is the notion of crowdfunding. Kickstarter style, for example, but without actually having a centralized intermediary like Kickstarter. So, in other words, here's what we want to happen. We want a completely decentralized system where some entrepreneur can ask for donations or contributions. But we should be technologically ensured that without the existence of an intermediary that that entrepreneur is only able to spend that money if they collect enough of it to reach a certain pre-specified threshold. So here's how we can accomplish that technically, just using Bitcoin. What the entrepreneur will do is create a single transaction with an arbitrary number of inputs that can vary as the process continues and a single output for, let's say, a value of 1000. And they'll send this around and try to collect contributions. And so, of course, any Bitcoin transaction has the property that it's spendable only if the sum of the inputs is greater than the sum of the outputs, or the single output in this case. And what'll happen is that this transaction will gradually accrue signatures from people contributing different amounts of money, and each of the parties will only sign her own input and the overall output. And this uses some features of Bitcoin, some little-used features of Bitcoin in order to achieve a transaction where you can produce only this limited form of signature. So the entrepreneur will go collecting these signatures, but the Bitcoin transaction will only be spendable if the sum of the inputs eventually reaches greater than or equal to the output value that's that's been pre-specified. So, this is something that you can actually achieve today on Bitcoin. But already we see that it starts to get into some little-known corners of Bitcoin. It's not the everyday type of Bitcoin transaction. But now let's look at another example, which starts to get even more confusing. And here's what I'm talking about. This is something called paying for a proof, and let me explain it in this way. Let's say that there's a hash function H and Alice claims to know some input x such that hashing x results in some constant c that's known to everybody. In other words, she knows the hash pre-image of some value. And now Bob would like to pay Alice in exchange for knowing this value of x. Now maybe this number x is the solution to some very valuable proof of work computation. But it doesn't need to be a hash function, it doesn't need to be an input to a hash function that Bob is paying Alice for. It could be the solution to any pure function really. And there is some arbitrary function F. Alice claims to know some input x such that F of x equals some known value and Bob would like to pay her for knowledge of this value. But, of course, once again security is a problem. This transaction happens over the internet. We want to make sure that if Bob does pay Alice, then Alice is necessarily forced to transfer knowledge of x to Bob. And one way in which we can achieve that is we can atomically couple Bob's payment with Alice's publication of x onto the block chain. So here, she's not secretly sending x specifically to Bob. But instead, she's publishing it onto the block chain. But maybe that's acceptable to Bob. So this is also something that can be accomplished. But it starts to get quite unwieldy with regular Bitcoin. All right. So now let's move to the second possible route, which I'm going to call embedding, and is also quite popular. And what embedding is all about is, it still uses the actually Bitcoin block chain. But instead, it comes up with some sort of arbitrary, maybe quite complex, representation scheme for encoding different real world semantics into the Bitcoin block chain. So, one example of this is colored coins, which you saw in lecture nine. Colored coins are sort of similar to the representation of car ownership and transfer that we saw in the smart property example. But it's a little bit more elaborate in that, in the car ownership example, the car doesn't need to scan the entire history of the block chain. It just comes hard-coded with a particular transaction out of the factory, and then it merely watches each block to see if that transaction gets transferred. Colored coins are a little bit more than that. The color of a coin, as it were, is defined by its entire history and where its genesis comes from. And so colored coins are a little bit more sophisticated to implement. But at the same time, it perhaps gives you a bit more. In particular, one interesting thing that it gives you is that everybody can agree upon what sort of transaction corresponds to transfer of a car ownership. And there can be something else for ownership of some other type of objects. And you can define as many of these colors as you want. So everybody can look at the block chain and know that a car sale has happened and how much was paid for it. But, of course, they don't necessarily know the participant identities. This could be regarded as an advantage or a disadvantage. And then there is also Mastercoin, which is also an example of embedding. It turns out there are a variety of creative ways in which you can embed arbitrary data into the Bitcoin block chain. A Bitcoin has something called OP_RETURN which is a type of script that allows 40 bytes of arbitrary data to be encoded. And you can also use fake transactions with non-existent addresses. You can exploit multi-signature, etc, etc. So these are all possible ways in which you can encode data into the block chain and thus embed your arbitrary transactions into the Bitcoin block chain itself. Again, it has some advantages and disadvantages. More complex representations obviously. But, normally one might think that for getting more complex representations you'd have to use an altcoin, an entirely separate chain altogether, that allows those representations. But instead, what embedding allows you to do is combine the idea of getting complex representations with utilizing the security of the Bitcoin block chain with all the mining hash power behind it. On the other hand, the scripting and atomicity are limited by that of Bitcoin itself. But the scripting could get even more limited than just using Bitcoin because these new features that you have defined, these new representations might not interact well with Bitcoin's existing atomicity and scripting properties. Another thing to think about is that it results in unwanted transactions in the Bitcoin block chain. Now, unwanted is a contentious word. This is a controversial property. Some people say that this is just fine. But some people say that you're using the Bitcoin block chain for unintended purposes, for purposes other than currency. And so they try to discourage this kind of use. I'm not necessarily taking a moral stance on this, but just pointing out that these are things that one wants to think about if you're using embedding as a vehicle for a decentralization. Now let's move to the third route which is something called side-chains which you saw in lecture ten. I'll just summarize what you learned about in a single sentence. A side-chain is a merge-mined alternative chain, so it still utilizes some or all of the mining power behind Bitcoin. And the value of the currency represented by the side chain is pegged into a one to one fashion because a proof of burden in either chain allows you to redeem coins in the other chain. And the typical use that is has been proposed for is a Bitcoin test bet. People want to try out different interesting modifications to Bitcoin and they want to do that without messing with the Bitcoin system itself, but still have interoperability of currency between these two systems. But perhaps we can use side chains with enhanced scripting properties, let's say, in order to achieve some of these complex contracts and other things that one wants to decentralize. The advantage, of course, compared to embedding, which it's somewhat similar to, is that you're not polluting the block chain, but the downside is that in order to even support the notion of a side chain, Bitcoin modifications are necessary. So who knows if this is going to happen, but if it does happen, it could provide another interesting alternate route. So now let's get to the final route for decentralization, which is having a totally separate alternate chain. And the best example of this is Ethereum which is really intended from the ground up as a platform, as a general framework for this kind of ledger-based consensus which you can use for all types of things, even creating your own currencies. And what Ethereum does, the key feature is that instead of Bitcoins limited stock based scripting language it provides turing-complete scripts. So this seems weird at first because it can lead to all kinds of problems. A mining node is trying to execute a script and it could get stuck in an infinite loop, for example. So Ethereum has a neat solution for this problem, which is that miner computation will be paid for using an internal currency called gas by entities within Ethereum. In particular, Ethereum has this notion of a long-lived contract which is sort of a program with a minimal amount of state that lives within the Ethereum block chain. It gets activated when a transaction is sent to it, it executes for a little bit on the minor nodes and then it shuts down. So contracts are these long lived things that have their own accounts and their balances and so on. And so they use that to pay for computation for miners. Now if you can achieve something like Ethereum, then it's pretty much a dream situation for a complex representations and animosity, you can take arbitrarily complex contracts and make sure you can represent them and execute them in an atomic manner, but the concerns, the challenges are more practical. Is something like this even possible? And since it's an alternative chain, will it ever have the sort of mining power necessary to make it really secure, at least in relation to using Bitcoin. And given that you're allowing turing complete scripts, what sort of unexpected security problems does that open you up to? So those are the things to think about when one is talking about a totally alt coin based solution like Ethereum. I should point out that Ethereum mostly exists in idea stage at this point, so it remains to be seen to what extent it will be realized as a practical system. But nevertheless, at least as a thought experiment, Ethereum is fascinating in thinking about what sorts of powerful contracts can be decentralized using block chain technologies. Coming back to smart property though, let's think about which of these approaches might be best. Well, from a conceptual point of view, any of these is powerful enough to accomplish what we want to, but when you start to get to more powerful contracts, then there're gonna be a lot of differences between the four approaches and the level of power and flexibility that they offer. But another practical consideration also to keep in mind is that various things like SPV, simplified payment verification proofs, are gonna be more or less feasible than some approaches compared to the others. All right, now let's go back to the car sale example and ask what happens if there is a dispute about the sale of a car. Perhaps the seller sold a lemon car to the buyer and now they're not happy with it and they want to reverse the transaction. Recall from one of the early lectures that we learned about escrow transactions, particularly a 2-out-of-3 escrow where in addition to the buyer and the seller, there is a judge or a mediator who's involved. And how might an escrow payment look like? So the buyer is going to transfer Bitcoins not directly to the seller, but instead to a 2-out-of-3 address, which is controlled jointly by the buyer, the seller and a mediator or a judge. And the 2-out-of-3 account has a property that if any two of them agree, then they can get the payment out of this intermediate holding address and get it back to either the seller, if the transaction goes through smoothly, or back to the buyer if there's a dispute and the transaction needs to be reversed. But in no case to the mediator's account, they can't steal the money. So that seems like a pretty good technical solution that we can use to build some sort of dispute resolution mechanism on top of it, but you might notice, this seems to lose animosity. This is a 2-out-of-3 escrow only for the payments, but as we saw earlier what we ideally wanted was to couple the payment with the transfer of car ownership itself. That also can be accomplished but it really starts to really get a little bit unwieldy at that point. Nevertheless, let's look at this sort of escrow and dispute mediation and compare that to the traditional real world solution and see what that gives us. So how would dispute mediation happen in the physical world with an actual dispute about a car sale? It would probably go through the court system. The court system is again a centralized, state controlled mediation process, but what this gives you is the freedom to choose the mediator. This is an entirely private contract between these two parties and they can choose that mediator to be whoever they want. And this could be a good thing in some situations. In particular you can argue that this notion of an intermediary for dispute resolution, which is the court system, has now been changed from a single entity that everybody must use mandatorily to a private market where different entities, different intermediaries can compete based on the perceived fairness, for example, of their dispute mediation process as well as efficiency, low cost, etc., etc. There are, of course, a lot of challenges of this sort of situation immediately gives rise to huge conflicts of incentive between the mediator, or one of the participants, they could be bribed for example. So those are things to think about, but one key disadvantage I'll point to is that in the escrow process, forget about even how the dispute mediation happens. In the escrow process that you must use in Bitcoin to even enable dispute mediation to take hold, you have to tie up the funds for the period during which either of the parties is allowed to dispute the transaction. And that's a little bit of a problem, that's not a problem that you have in the traditional system. And the reason for that is that in the court system if there is a dispute and one of the parties refuses to pay up, you have law enforcement, you can go after them, you have their identity. And that's something that's lacking in this system, as well as in any of the alternative routes. That we've looked at in order to achieve decentralization. And we'll return to this point again. But the broader point I wanted to make here is that, while earlier, we saw an example of decentralization through disintermediation. Completely getting rid of an intermediary. This is also a different form of decentralization, but it's not dis-intermediation, instead, we've replaced a single mandatory intermediary with the freedom to choose your own intermediary. And we've seen this before, we've seen this in a different context. In a previous lecture, You saw the notion of decentralizing prediction markets, and what we did in that situation is also we allowed, instead of a single party like Intrade running everybody's prediction market. We said anybody can now start a market. That's really lowered the barrier to entry. If somebody wants to run a prediction market for the next presidential election go for it, someone else wants to run a prediction market for the Super Bowl, they're free to do so. In fact multiple people can run different prediction markets for the same event. There's nobody stopping them, so you have this competitive market for intermediaries. So that's another sense of the word decentralization. Okay, so let's put what we've seen in a spectrum. On the one end, in terms of the most centralized system, is a single mandatory intermediary. We also just looked at multiple competing intermediaries. And there's one more intermediate step which I'm calling a threshold of intermediaries. We haven't looked at that so far, we'll see that near the end. But finally what we started out seeing, with smart property, is complete disintermediation, no intermediary. So I would put all of these on a spectrum. It's not completely distinct categories but it's useful conceptually to sort of think of them that way. Now let's think about another aspect of all of the protocols that we've seen so far, which is security. We started out by saying animosity is a very important way to achieve security. It's not the only one. We said there were gonna be some alternatives, so what are they? So here are some ways of improving security. We've seen two of these, the ones in the middle. Escrow with dispute mediation, as well as Atomic exchange, which completely automates the process. But there are others. And in fact, the most obvious one perhaps, is Reputation, where you don't have any particular technological security enhancing mechanism. But instead, these intermediaries, or whoever the parties that you're interacting with, build up reputations over the long term. And so they build some trust in that manner. Reputation is okay, in the absence of other security alternatives, like Atomic exchange, but it has some problems. First of all, the entity has to build up this reputation over the long run. Right, if whoever's the entity you're interacting with has completely pseudonymous or anonymous then reputation doesn't even apply. And we see this problem even with real world reputation systems, for example restaurants or other businesses. That obtain really bad reviews on Yelp. My close and reopen may be in the same location, maybe in a different location, but simply re-branded. Right, so that's a problem in general with reputation systems. Also for the party to accrue positive or negative reputation, there should be a way for establishing what they did right or wrong that just goes beyond he said she said. So looking at Yelp again, it does work on a he said, she said model which sort of works okay because there are real identities in Yelp, and people sort of have to use their real names, and of course, businesses operate under their real identities. But here we're talking about a universe in which, everybody wants to be pseudonymous, and so this sort of a model where it's one person's word against another might end up really becoming a nonstarter. There are also problems with Escrow and dispute mediation. We saw a couple in the way that Escrow is done on Bitcoin. You have to actually tie up your funds and they become unusable during the time when either party has even the ability to challenge the transaction. And of course, dispute mediation leads to conflicts of interest and so forth. We've seen atomic exchange, whenever it is technically feasible, then it's probably a good idea. And the last thing, another thing that's been proposed is Trusted hardware. It's not always applicable, but in some cases, for example, it's applicable when the service that you want to pay for is something that's entirely a software program. And so what the developer could do is publish the code and execute it on a trusted hardware module. And so the people who are subscribing to that service, or paying for that service, can be assured that the code that they can look at and audit is the same code that's executing and providing them the service. But what is really common to all of these ways for improving security in terms of the block chain base decentralization paradigm, is that ultimately there's no real world enforcement. There are no physical identities, there's no law enforcement, there's no going after people. And so that means two things. One is there can be no debt. If we want to do dispute mediation, the lack of the ability for debt is the reason why you have to put in sort of a deposit and lock up those funds during the period when you want dispute mediation to be possible. Also, there are no punitive measures for misbehavior so this really limits the sort of things you can do. So these are important limitations to keep in mind. Okay, a little thing that I want to point to is that in terms of the vocabulary of security. Some people use the word Trust minimization. I don't like this term at all. I feel that there is often confusion between two things. One is the fact that cryptography is often used in contexts where, unfortunately, there is not much trust between entities. And so the lack of trust is a starting point, and cryptography is the solution. This often become confused with, oh now we have this hammer of cryptography. Let’s try to use this to move to a world where nobody has to trust anyone anymore. And so trust minimization is not the goal. Lack of trust is not the model that we're hoping to move to. It is instead our unfortunate starting point. But really trust is not really the right lens to look at it. It's not whether you trust the motives of some individual but whether they're going to behave in the manner that they have specified and that could be because not only because they're untrusted but because they got hacked, etc., etc.. So let's not really use the word trust and instead talk about security. All right, so let's summarize a lot of what we've seen so far. One of the things that we want to talk about in terms of decentralization is what is being decentralized. We've looked at a couple of examples, smart property, pay for proof, and so on. But we're gonna see a lot more. So we haven't really talked about the first bullet. Instead the three things that we've talked about in this section are what type of block chain integration. We saw four examples directly on block chain, imbedding, side chains and a totally different, alternative chain altogether. We talked about levels of decentralization. Again, we talked about four points on a spectrum ranging from completely dis-intermediated to completely centralized. And finally, we talked about different ways of enhancing security. So key points that I want to make in this lecture and that you'll see through the next several slides. Is that asking these four questions gives you a powerful engineering decentralization template that can be used to understand and succinctly represent almost any of the proposals that you see in the Bitcoin community for block chain based decentralization. Let's go ahead and see some examples of this. Let's go back to smart property once again. So what is smart property. It decentralizes the notion of property ownership in trading. Which are two related but somewhat distinct things. And it decentralizes in the sense of disintermediation. You don't need an intermediary anymore, like the state or the DMV. And in the example that we saw, it was achieved using the Bitcoin block chain itself, but you could achieve it using any of the other three methods. And finally, the key security principle that we used was atomicity and tying together the payment with the transfer of the car ownership. Now let's look at another example, which is also something we alluded to a bit earlier in the lecture, which is prediction markets. So of course, it decentralizes a centralizes prediction market like in trade and it does so in the sense of competition. It doesn't get rid of the need for some entity to run a prediction market, but instead it allows anybody to do that. It lowers the barrier to entry and different people can run different prediction markets and it was done using an Altcoin. And again, the security property was atomicity in that the two parties to a trade of a share in a prediction market are coupled together using this atomic property that ties together the transfer of the share with the transfer of payment. Now let's look at a quite different example. This is something that's called a StorJ proposed by Greg Maxwell, who claims it should be purposed storage. But I'm gonna ignore that, because it's just gonna be confusing if I called it storage. So what this is, it's sort of an agent that lives in the cloud. What do I mean by agent or at least what Greg Maxwell means by agent is that it has some level of independent decision making ability. It is not full fledged AI, but it decides some things for itself. What it's going to do is, it's going to rent cloud computing services and it's gonna use that to run itself. But the service it provides to consumers is that you can pay this agent to store a file for a certain period of time say, 24 hours. And when you do that, it's going to receive payment in Bitcoin. Store this file, keep it for 24 hours and then delete it unless you keep making payments. It also has some other very interesting aspects, such as reproduction. It can take a copy of the codes upon a new instance and try to make improvements to it, pay somebody to write new improvements or modules and so on. But we'll ignore those aspects for now and just talk about this aspect of it. So what is StorJ and can we look at it through the lens of decentralization? It turns out that we can't. So StorJ decentralizes the notion of file storage and retrieval, which you can do today through Dropbox, for example. It's decentralizing the sense of competition. You still need an intermediary very much, which is this agent and the payment is done using Bitcoin. And finally, the security mechanism that you have is just reputation. There is nothing in particular in the StorJ proposal that, for example, atomically couples your payment for storage with the actual act of retrieving the file. So that's StorJ. Let's look at more examples. In fact, we can even consider Zerocoin, for example, which we saw in a previous lecture through this lens. So Zerocoin is a way to decentralize the notion of mixing, instead of having a centralized mixing service where you put in your coins and just hope that you get it back. It's decentralized in the sense of disintermediation. There is no mixing intermediary anymore. The mixing is accomplished purely through cryptography. You don't need to trust anyone, it's enforced just by math and by consensus. And it's done using an Altcoin, it's not quite compatible with Bitcoin unless there is a fork to Bitcoin and the security property is atomicity. What does this mean? The notion of burning a base coin and Zerocoin and actually getting a Zerocoin it exchange for it are atomically coupled through the same transaction. And the same goes for later redeeming a Zerocoin and that's where the security comes from, that's why you don't need to trust anybody. And that is of course, accomplished through zero knowledge proofs. So we've seen this powerful template that incorporates these four factors. And we've seen some examples of how systems that we've already looked at fall into this pattern of decentralization. In the next part of this lecture, we're gonna look at a variety of new examples of things that people have purposed can be decentralized using block chain technology and we're gonna use this sort of template to analyze them.
