Scaling Bitcoin workshop : Stanford 2017

Microchains

David Vorick

I would like to see a blockchain ecosystem with 1000s of transactions/second at layer 1 with full security. And so, we have to look at blockchain differently if we are going to achieve this.

A brief introduction... my name is David Vorick. I have been studying bitcoin since 2011. My primary gig is Sia. I have been spending a lot of time on consensus algorithms and proof-of-work. If we could start over what sorts of things could we do today that we didnt know about in 2008? Today I want to present a new way to think about blockchains and a new way to think about game theory that will allow us to depart from the traditional security assumptions of bitocin and to present a new way to secure transactions against double spends without considering the 51% attack threat model.

The general idea here is that to get scalability we're going to switch from these large monolithic ginormous chains where everyone has to do validations, to a model where there are many tiny chains. Every user will be on many chains, like to 20 to 100. So every user will be validating a small fraction of the ecosystem as a whole, and then use cross-chain lightning so that any user anywhere in the network can send any user to anywhere else in the network. The hope is that by breaking the chains apart we can reduce validation costs and increase the overall scale of the blockchain ecosystem. We already have bitcoin, litecoin, ethereum and so on. Users on any chain can send money across chains without validating the whole transaction set on every blockchain. This is taking it ot the extreme.

If you have a million chains with separate currencies and separate PoWs is that 51% attacks become really easy. If you have chains iwth market caps of only $100k then you only need a couple GPUs or ASICs, and one person could easily afford enough hardware to go 51% attack one of these chains. And so what I want to do is present a way that we can present these chains and make them safe against double spend attacks even though they can be trivially 51% attacked. We need some new pre-reqs that I will walk through.

The first thing I want to inroduce is the idea of open mining where miners instead of hashing and getting rewards is that they have an API where you can give a miner a random header and pay them to solve them. So as long as they get more money from your payment, they have an incentive to return a solved header and not have an yidea which chain they are solving for or what chain they are doing or what the transactions were or anything. We want to be able to pay for hashrate without having hardware.

We are also going to need a way to have high full node participation. We want every user to run a full node that has a lot of uptime. A good example of a high uptime device that everyone has is a cell phone. So we want to not slow down the phone and not impact battery life. We want to not use up all your data allocation. We want to see chains where the majority of chains are full nodes and everyone is fully validating.

And finally, we have this third idea of mutual discouragement which is that if you're on a chain and you see an attack happening successfully, you just lose faith in that chain and you stop transacting on it, maybe you sell your coins, you stop buying the coins, you lose faith in the chain.

Open mining is not that bad of a pre-req because it's pretty reasonable if there's a substantial amount of money to be made by opening your hardware and accepting payments to do random hashing I think miners could be comfortable doing that. If miners can make more revenue, then I think they will do it.

Hig hparticipation is probably hard to get. I don't know if users-- typically they don't run full nodes. Hopefully we can run a system tha twould be easy. You just run a full node and you ... to make one.

And mutual discouragement; I think this would work because you have lots of chains. If you see one... if one of their chains gets attacked, you probably don't want to be on that chain anyway, and it's not a big loss to you, so I think users would be comfortably on board. And there's a revenge component on the human psyche that we can tap into.

So the advantage of open mining is that any user can 51% attack any one of the millions of chains. You have miners and hashrate power and it can be bought at any time, then you can dump like the entire market cap of a coin worth of PoW in it within 2 hours or something. So the bitcoin equivalent would be like redoing the entire chain 10 times over and so on. And so, if you have the ability, it's not just like, it's not just attackers have the ability. It's the funders as well. Anyone can dump as much chain on as much as they want whenever they want. If you see an attacker trying to do a reorg or a double spend, you can add work to the honest side of the chain to defend it. And this is going to be ultimately what pulls everything together.

The reason why we need high participation and lots of full nodes is that if you come lonline in the middle of an attack, you can see there's a double spend, two chains, they are conflicting and one is trying to win, you have no ideas which one was originally there. But if you were online there, you can probably see after six hours, and someone trying to do double spends, you are aware of which one was original, and the only way to tell in the middle of an attack or even after, which wside was the original or the good guys, is if you were watching the whole time. So thats why we need high participation.

So how do you prevent double spends? the most basic thing we can do first is a scorched earth game where if you do a double spend as an attacker, you are stealing from someone. If the defenders are online and watching this attack, they have revenge motivation, perhaps they are more motivated than the attacker to defend it and protect their payment. If the attacker has to deal with a motivated defender that can dump work on the chain, then the incentive for the attacker goes down, and everyone will lose money, and net everyone is out. This is not fantastic, but it means that the incentive to attack has been reduced.

More interesting is this mutual discouragement thing, and if I'm online watching an attacker and defender battling and I see the attacker winning... if he can win once, then the coin is probably not valuable since he can win again, if I receive coins, they might be double spent. So I'll just sell off. If you have a bunch of participants on your network and selling off, the watchers are going tobe the exchanges, miners, etc., and everyone will switch to selling coins, nobody is buying coins. The immediate value for this coin turns to zero. The attacker who just did a double spend to steal some of these coins, really stole nothing, it's now worthless. So this is a big disincentive for an attacker to try to engage in a double spend.

The final thing that we can do is that if I am sitting on the chain and I have $50 of you know coins on this chain and I see an attack in progress, then, I know that if the attacker wins, that $50 is going to be worth approximately $0. I am going to want to sell it off, and nobody is going to want to buy them. I have $50 of motivation to help the defender. So the approximate outcome is that the entire market cap of the coin is motivated to assist the defender any time there is an attacker, so as long as you can pay hashrate to go defend the blockchain. So the result is this interesting game theory mechanism where an attacker is just-- een if a cahin has a low amount of work oer time, an attacker has an oerwhelmming barrier to commit a successful aluable double spend. I think this is just a fascinating idea.

I am going to make one more obseration. If you hae really tiny chains, you don't need transaction pools or mempools. If you have a huge number of tiny chains, you don't need a transaction pool. You could do 1 tx/block. Their throughput is low anyway. When you want to make a transaction, instead of waiting for someone to mine a block, you just mine one yourself. You dont have to pay the fee if you're the one mining the block. So the people who are paying for most of the work on the chain are going to be the users because the miners can at most make the block reward. If there's no transaction pool, you're at a disadvantage as an economic party, ompared to people who are making transactions who have extra utility to do mining. So we get rid of headache of transaction pools and we decentralize the mining component a lot more. The hashrate might be a place where people pay to do the PoW and the actual like power house behind the PoW is a lot more decentralized among the people doing the transactions.

I think that another big advantage to microchains is that they are anti-fragile in the sense that if I am on 200 chains and somewhere in the million chain ecosystem and things are melting down and going completely wrong, it doesnt effect me at all as long as whatever part of the ecosystem I am in is still in tact, it doesn't matter if things elsewhere are melting. If we try to spread this out over a broad set of use cases, I could imagine some of the use cases are going to have an easier time having high participation. For example, a bunch of banks doing business with each other.. it's a lot easier for a d ubsines funning full time ndes more than it is for users. So we might see use cases where businesses can fit into this game hteory moeedel a lot easier than every day users. This is something we could experiment with users over time. Or even simultaneously. If one set of use cases ends up not working out, it doesn't effect the rest of the uzes ases. With a microchains environment you can do a lot of aggressive experimentation and because they are smlal hains that don't influence each other, you don't have to worry about every single soft-fork and eveyr single upgrade being absolutely perfet. You can just make more chains each time you have more ideas.

I would propose that if we were to make this, we would brand it just like bitcoin in the early days as extremely experimental. High risk, expect to lose money, and then we start to play around with potential microchains. Since they are supposed to be secure at the low market caps due to the game theory incentives, it's not risky to play around with it even if the whole market cap of the thing is like $10 bucks, you might be able to see some of the game theory play out. That's the end of my talk, I'll take some questions.

Q&A

Q: These microchains feel a bit like the value in the original Fugger's ripple system where the value of what you have depends on your network and your friends and how well they will support you in the end. How would you discover the correct price if you want to do a cross-chain swap between the coins?

A: The price would have to be handled by layer 2 infrastructure. You want multiple market makers to be on every chain. You would ask the market makers who trade them all day, what's the best price you can give me? if there's a large enough of market makers on your chain, it's unlikely that they will all be colluding to give you an unfair price. The spread will be visible. You can tune your trading according to what makes sense given the liquidity and spread. So I think this is handled with layer 2 supply and demand mechanisms.

Q: Worth of your chain should be based on your previous attack history and how many of your friens and cohorts came to your defense.

A: If you had a chain with a history of several attacks that it successfully defended, it would probably be worth a lot more than a chain that hasn't bee ntested. Once a chain fails once, it's probably dea dforever. There might even be reason to attack a chain- like attempting a double spend on your own chain, just to verify that the network is really on standby. If you are going to spend money mining blocks that will be displaced by the network's immune system... it might be worth throwing those blocks away to confirm that the network has a functioning immune system.

Q: I think in a lot of this you are making an assumption that you can see an attack happen. In bitcoin, PoW's purpose is to detect sybil attacks. How do you detect that in microchains where the cost to do a sybil attack will be much lower?

A: In terms of attack visibility, I think the only assumption that we really need is that you are connected to the full chain and so if you're on the p2p network and there's no partition between peers, then either you know about all the work that has happened or there is work that is being kept secret from everybody and is suddenly revealed then that's an attack. You can detect the attack by a sudden amount of large work being revealed that causes a reorg and you have to assume there is no network partition. If you are able to partition the network, then when you combine the partitions, both of their immune systems would react and it would probably end the chain.

Q: That's a similar assumption to proof-of-stake.

A: I would say its better than proof-of-stake in a lot of other ways. One of the huge benefits this has is that if I am bootstrapping to a network, I have absolute certainty by the amount of proof-of-work on a chain, that I have bootstrapped to the right chain. Whereas PoS has the costless history problem, which this does not.