So we’ve talked a lot about how to decentralize. Now I’m going to give you a taxonomy of the different things that we can decentralize. At least, we know technical solutions for how to do these things. And this is where a lot of the excitement is around for using block chain technologies. So the first category is things that are purely digital. And perhaps the most basic example of this is name mapping, what do I mean by this? Name coin is a good example. It's a mapping between human readable names and addresses. And so as long as you have something that's purely digital, it's a simple matter to use consensus technologies so that different participants can enter new values into the system, change values and so on, or read values back, and the block chain can be used as a record of the current state of that mapping. So the next two are storage and proof which we've seen earlier in this lecture, storage A and the paper proof idea that we saw earlier. These are sort of complements of each other. One is paying for storage, of course, and the other is paying for computation. You can also have random number generation. What does this mean? This is something you saw in a previous lecture, using Bitcoin as a beacon. So a beacon is something that ahead of time nobody should be able to predict. But once the beacon value has been generated everybody should be convinced that the value is in fact generated truly randomly. So again, bitcoin is a good vehicle for doing that. And lotteries, at least if you were talking about lotteries where the payment and payout is denominated in the currency of the block chain itself. Then running a lottery reduces to a random number generation problem of picking one of two input addresses of a transaction to use as its output address, basically that's what it translates to. And so you have a centralized bitcoin lottery systems like Satoshi Dice, but certainly it's fairly easy to imagine doing these in a decentralized manner as well. Let's move on to the next category, which is things that aren't inherently digital but can be represented digitally. This is a big category, real-world currencies of all kinds, stocks bonds and other assets and so on. This is where perhaps a huge amount of the excitement is of how to use block chains for other things. And so what does this mean? Let's look at colored coins as one example of the specific mechanisms that you might use for decentralization. If a particular color were to represent a particular currency and some other color were to represent a stock of a particular company, etc., etc., then you have all these assets that you can transfer between participants and you can pay for and so on. And so you have trading of any of these assets, and also you could have atomicity between the trade of the asset and the transfer of payment. That all sounds well and good, but here's the real problem. What is the mechanism to ensure that what you're calling one dollar in terms of colored coins is actually worth one dollar. That could happen if some banker or consortium of banks agrees that they will back, using their deposits to there physical bank accounts, the corresponding colored coin. If there is some entity that promises that one to one pegging, then you're good. Similarly, if there is a company that agrees to actually release stock in a digital form or agrees that they will treat that digital stock as equivalent to their physical or real world stock, then you're good. But otherwise all that you've done is invented some new thing that you're simply calling dollars, for example, but whose price is floating freely with respect to actual dollars. So in other words, you've just invented a new currency, and inventing a new currency is not an accomplishment at this point and in fact we have a surfeit of these things using block chain technologies. And so, that's the real challenge here. It's not so much representation, but this economic problem of actually ensuring an equivalence to the real world analog of this. And, most of the proposed solutions for this don't solve that harder a problem, except maybe one, which we'll look at near the end. Let's look at the third category, which is property ownership and trade, which is what we started by looking at. We can decentralize that using smart property and atomic exchange, and these two are ownership and trade related. They're not quite the same thing, but you can't completely separate them either. And hopefully, the discussion at the beginning of the lecture has given you a good understanding of how to decentralize this. Now, the fourth category is going to be more complex contracts. Trade can be thought of as a very simple contract. You give me this object in exchange for a certain amount of money, but you can have more complex contracts like crowd funding, which is also something we've seen, but also financial derivatives which is another big area of excitement. So what are financial derivatives? Derivatives have an underlying asset and the value of the derivative depends in some way on the price movements of the underlying asset. The key thing about a derivative you can think of it as sort of a conditional statement that depends upon the price of the underlying asset some time in the future and so forth. And using this kind of language, you can express quite complex statements. An example would be you can have a contract between two parties that says, for this asset, if the value goes beyond $5 past a certain date, then for every dollar that it rises above $5, you owe me $2. So that would be a way to hedge your belief that the value of this asset is not gonna rise beyond $5. So again, you can do financial derivatives using some of these systems, especially some of the more expressive altcoin-based systems are a great vehicle for this. Now one nuance to note is that these conditional statements depend upon the price of the underlying asset. And so whatever script or other mechanism that you have in your block chain system that depends upon this price should have a secure way of knowing what this price is. And this is called a data feed that you saw a bit earlier, we're gonna see again later in this lecture. But one possible way of getting around this need for a data feed is if the underlying asset itself is traded on the same block chain using the asset decentralization idea that we saw a couple of slides earlier. And so, if that is happening, then some sort of price discovery might be possible, but again you have to worry about whether this price that you are discovering through the block chain itself is reliable or whether it could be hacked by somebody creating artificial transactions and taking both sides of it, for example. So, this is all not quite fully understood, but there is a lot of excitement around it, a lot of proposals, and it is certainly possible that some time into the future this is going to get much better worked out and we might have some sort of working system for trading in these things. So the next one is something that's even more in the sort of vague idea or proposal stage but also there's a lot of excitement, which is decentralized markets. So let's talk about markets and auctions for a second. Let's forget about decentralization. Let's look at some real world examples of things that act as markets and see exactly what features they provide in order to gain a better understanding of what it means to decentralize things. In fact, let's look at four examples. A used bike store is basically where you go and sell your bike and so you have a separate transaction with them, selling your bike for money. And then they have a separate transaction with somebody else, reselling that bike and you don't directly interact with the person who eventually rides away with your bike. So that's one model. Another model is eBay, which only matches participants and routes payments. PayPal is a payment processor. They don't match participants, but another function they perform is that they do a limited level of dispute mediation. And finally, you have the Craigslist model where they're not actually involved in the exchange at all in any way, except for matching participants together. So we've identified several different functions that these markets give participants, and let's see what we know so far about how to decentralize each of these functions, and what to do about the rest of them. So the most obvious one is payments, and of course we have crypto currency for doing those. We have transfer of actual goods, which we can use smart property for. Further, we can leverage atomicity to couple the transfer of ownership of goods with the transfer of the payment. And we know how to do a limited form of dispute mediation using this escrow process. But what we have not seen so far at all is how to match participants who want to take different sides of a trade. And that's what I want to tell you about now. So now I'm gonna show you a not fully fleshed out idea, but hopefully enough to give you an intuition. An idea for how to do this kind of decentralized matching. Let's go back to the car example, let's say Alice wants to sell a car. What she's going to do is she'll create a transaction, a partial transaction, not a fully complete one yet, that contains the necessary information for transfer of ownership, as well as the sale price that she wants, the minimum price that she'll accept, and broadcast it onto the network. It's not a complete transaction yet, it won't get onto the block chain, but it will get broadcasts nevertheless. Now the counterparty, someone who wants to buy the car, is going to find the transaction, determine that it meets their criteria for a car that they want to buy. Perhaps this transaction has encoded information that has a webpage or just within the encoding itself, all the things you need to know about the car that you want to buy. So as I said, it's not a fully fleshed out idea. So this counterparty completes the transaction, they sign it, and then they broadcast it once again out to the network. At this point, the transaction is complete. It has all the information that it needs to get onto the block chain. And so the transaction is automatically complete. Of course, this is a bit of a crude idea. It's hopefully enough for you to get the picture. One wouldn't necessarily want to do it this way. For one, it's very inefficient. Every partial transaction that represents somebody wanting to sell something, needs to be broadcast to everybody in the network. But other than that, there's not a whole lot of control in the matching process. But it's something, it's a basic way to decentralize this idea of the buyer finance seller. There is a variance you can use, which is that instead of partial transactions being broadcasted onto the P2P network, you can have partial transactions under your chosen representation. But nevertheless, are complete transactions in terms of the underlying encoding unto Bitcoin. And so you could have these offers for the car, for example, be an actual complete Bitcoin transaction that gets onto the block chain. And so only when it gets into the block chain will it get noticed by potential sellers, and then they will continue to process that and take you to the next stage. A variant of this is the auction, where you create your transaction in such a way that the buyer cannot simply complete the transaction broadcasted onto the network and finalize it. Instead what they'll have to do is they'll have to assign it and then return it back to the seller or the auction creator, who will then further need to sign the transaction in order to be fully valid, to then complete that transaction. And this allows the seller to acquire different bids from different potential buyers and pick the one that she likes best. Another interesting variant of this is the double auction. A double auction happens when you're buying and selling stocks, for example, where it's, the offers are coming from both sides, the offers and bids. And so what you need is some party in the center that's matching these offers and bids together. So one way in which you can achieve that is you can actually have the miners to match these orders that are being broadcast onto the P2P network. And you can allow the miners to keep the bid-ask spread, which is the difference between the bid and the ask. And one good property of doing it this way is that It avoids miner front-running. What does that mean? It means that when the miner finds a really good offer, then they can ignore the bid that's coming from some other participant in the network, create their own bid, and complete the transaction, and get a better deal than they otherwise might have. All right, so now lets move on to data feeds. We looked at this a little bit earlier let's look at it in a bit more detail, you've also seen it in a previous lecture. Data feeds are a way for what we'll call arbiters to assert real world facts into the Bitcoin block chain. And there are some very natural applications of this. If you have a feed of price movements that allows you to implement derivatives, if you have feeds representing outcomes of events, that allows you to implement prediction markets and so on. So data feeds are not necessarily interesting for their own sake, but for the things that they can help you implement. So allowing these arbiters to assert these facts is already a step better than having a single designated entity that's going to create all of these data feeds. So this is a form of decentralization in the sense of competition between arbiters. And this is what we saw in the example of decentralizing prediction markets. There are also other means that one can use in order to improve security here. You can use trusted hardware. For example, you could write a script that parses finance data, for example, from finance.google.com, and uses that to create a data feed of stock movements. And what you can do is you can put that on trusted hardware, so that anybody can verify that the script is actually doing what it's claiming to do. This still leaves other things that you have to take on trust, for example, that Google is not lying to you or somebody is not tapping the connection between the script and Google. You have to rely on HTTPS for security, etc. So those are not perfect solutions. There are no perfect solutions here. Ultimately, data feed require somebody to actually do the active importing from the real world into the block chain, but here's something interesting we can do. With data feeds we can have a threshold of different arbiters. And that's particularly useful because inherently there are big incentives to lie for these arbiters when the data feeds that they're putting onto the block chain affect the outcome of contracts, for instance. So what do I mean by a threshold of arbiters? Let's look at a concrete example. Here is one way to implement a data feed. A centralized version, or a somewhat centralized version where you still have individual arbiters as competition between arbiters and so on. How that might work is, let's say there is an event E with outcomes X, Y, and Z, corresponding to maybe the presidential election or something like that. Then this event E corresponds to this transaction in the block chain. Everybody agrees upon this representation. And when an outcome happens, this transaction will be transferred to one of three different addresses corresponding to X, Y, and Z. And of course it'll be signed, this transaction will be signed by the arbiter A. And by looking at which public here, which address the transaction was then transferred to, you can figure out which outcome happened. So this is one way of implementing a data feed. How can we decentralize this data feed in terms of a threshold of arbiters? Let's say we want these arbiters to be able to declare an outcome only if two of three such designated arbiters agree that X is actually the outcome that happened, and not Y or Z. So how can we implement that? Recall that Bitcoin has a multi-signature feature. So what we would do is, we would make sure that this transaction output is a two out of three multi-signature address that is controlled by these three different arbiters, A, B, and C, each of them has one of the corresponding private keys. And so only if two of them agree, let's say A and C, then they will be able to create this transfer transaction. So that's a way of decentralizing this notion of a data feed so now we can go back to the picture that we had earlier of the spectrum of levels of decentralization. So now we've seen an example of what it means to have a threshold of intermediaries which is a distinct concept from having multiple, competing intermediary. Let's now move on to another thing you can use launching technologies to decentralize. This is something there has been a huge amount of hype about, called autonomous agents. What are autonomous agents? Different people have proposed this and so in different conceptions there have been different sets of features that have been proposed. But here is a good set to focus on. One is that these agents will be able to enter into contracts with other participants. They will have data feeds from the real world as a way of having real world input into these contracts. And these agents might perhaps have shareholders, or some other manner, in which humans can vote in order to change the rules by which the agent operates. So that's a key distinguishing factor for many of the ideas that we've seen before. And some variance of this notion of an agent also has some idea of reproduction, mutating the code and improving with time, etc. This is again quite hypothetical concept. There are a number of challenges to realizing this in practice. One challenge is going to be is this agent something that needs to keep private state, or is it something that will truly execute on a transient basis on the minor notes? And if it does need to keep private state where is that going to come from and how can we decentralize that? And is it even meaningful to talk about decentralizing it? Another challenge is this funny problem of a sort of hostile takeover. If there is this notion of voting to change the rules then is it possible that whatever constitutes the shares of ownership of these agents, somebody could buy it up, acquire 51% of the shares and then vote to change the rules. So that all of the agents of the asset, for example, will be transferred to this party who's doing the hostile takeover. And this is a problem should there be defenses against this. So there are a number of open questions here. I will make one point, though. People call these decentralized autonomous agents, the decentralized version of this. They also call it decentralized autonomous corporation. This is not a technology that I like very much. I feel that this vision of decentralized agents misses all of the important or assailant features of a corporation which is all the legal backing that goes into it. And so it gives it a certain kind of rights and responsibilities in the real world where as we're in this parallel universe where everything has to be defined and enforced by technology so I don't feel it makes allot of sense to call it a corporation. Agent is the term I prefer. All right here's the final category that I want to tell you about. And this is quite interesting because at first sight it might look like there's really no way of achieving decentralization here. So what are we talking about? Exchanges. What do I mean by exchanges? It's all well and good to represent some sort of colored coin for example as representing US dollars and then to trade that. But ultimately, if you want actual exchange between whatever you're calling US dollars and real world US dollars, you need something more, and that can be illustrated using this problem. Alice would like dollars in exchange for Bitcoins, and Carol would like the opposite. It seems like they should be able to trade with each other, but there is no real way of doing it over the Internet in a situation where they don't trust each other. Because one of them has to send the other Bitcoins and then hope that this person is going to mail them cash or use PayPal or whatever other way of transferring real money. What do we do about this? Well, maybe they have a mutual friend Bob, then this simplifies things a lot. What they can do is Alice can have a separate transaction with Bob. And since Alice and Bob are friends, Alice can send Bob Bitcoins, and trust Bob to send dollars over some other mechanism. Or even meet in person later and send dollars. And then Bob can do a similar transaction with Carol. So this intermediary has neatly solved the problem. But this still seems to have a lot of limitations because they need to have this mutual friend with each other. What if they're on opposite sides of the world? So here's how we can solve that. First of all, we can make this a bit more efficient. Instead of calling this a transaction where Alice sends Bob Bitcoins and Bob sends US dollars back to Alice. What we can say is that Bob simply sends Alice some kind of digital token representing the fact that he now owes her some amount of money, let's say $100. And we know really well how to do this, this is exactly the same as some sort of digital asset. We know how to represent this in a variety of black chain based technologies. And similarly, Bob could have this transaction with Carol, so the only thing that would actually happen is Bitcoin's changing hands, as well as this new relationship of debts being represented in the system. So this gives us a starting point for scaling this up to an arbitrary scale, even to the scale of the whole world. Let's imagine a social network that represents the trust relationship between all pairs of friends, and so what could happen here is there could be a complex chain of interactions through which a node here exchanges Bitcoins with a node here in exchange for US dollars or whatever currency. And it would simply be represented in the system as a series of IOUs. And what would make all this work is that in the system, pairs of friends must pre-declare how much debt they're willing to extend to each friend they have. So Alice might be willing to trust Bob to owe her $100 and be confident that he repay her that amount. She might have a different relationship with Dave and other users, and so on. Another neat feature of this whole system is that if there are a variety of these debts that are expressed in terms of the edges of this graph. Let's say you have a triangle of users successively owing each other. Then you might be able to simply cancel out that debt within the system. And so if you have a reasonable number of trust relationships, and if you have a good amount of liquidity in the system, you might be able to go a long time and keep doing a lot of these transactions and not accrue too much debt overall in the system. Because a lot of these debts are going to cancel out in the long run. So that could make the system quite efficient in the long run. So this is a simplified version of what Ripple does. Ripple is what you might call an Altcoin, but it's a bit more than that. It has its own consensus mechanism. It's not exactly based on proof of work, but this notion of trust relationships and IOUs is something that's central to Ripple, and what it allows you to do is disintermediate the notion of currency exchange. So in other words, we've decentralized a currency exchange in the sense of disintermediation using an Altcoin and the key property that we've used, earlier we saw atomicity and so forth. We used none of that here. We used something different. We started with a limited amount of trust and we used the transitive property of trust to take that up to the level where it can scale to all of the participants in the world. And in Ripple as it currently exists, at least as I understand it, most of these participants are not individuals but instead banks and other institutions. But you can certainly imagine the exact same kind of network working for individuals as well.
