Haseeb-Qureshi/cryptoeconomics-mental-model.md

## cryptoeconomics-mental-model.md

      
    Raw
  

              cryptoeconomics-mental-model.md
            
          
    Cryptoeconomics Mental Model

Vitalik Buterin, Joseph Poon, Karl Floersch

What's new?


Karl: A lot of recent progress in Plasma Cash.


Vitalik: Ethereum core has basically had most of the hard problems essentially solved. Only a few details that need to be hammered out—more efficient Merkleization, how to rotate validator sets, etc.


Joseph: how to coordinate inter-chain communication? How to coordinate faucets, airdrops, to enable different kinds of social coordination.


What mechanisms that people are excited about scare you?


Vitalik: On-chain governance. Many people like the idea of blockchains being fully automated, doing upgrades without complicated social consensus. At the same time, people think about governance mechanisms with less cryptoeconomic rigor than they think about consensus algorithms. On-chain coin voting are extremely vulnerable to collusion, bribery, have strong plutocratic incentives. Have been many high-profile cases of collusion being discovered in reality. Large actors in cryptocurrency ecosystem won't pass up opportunities to profit.


Karl: The free option problem with HTLCs / atomic swaps. Many people have been discussing this problem. Have had to deal with this in Plasma DEX designs. Miner frontrunning as well.


Joseph: Scared by information asymmetry. Big disconnect between public perception and what the researchers in this space are thinking about. You see many dynamics where people are working on consumer-facing projects while not understanding how early stages the technology is currently in. Many cryptoeconomic mechanisms only work if there's a lot more research done on P2P oracles. Decentralized oracles are a big dependency of many designs and projects, and only one or two even testing how to build good designs.


Why haven't we seen more engagement from traditional mechanism design?


Karl: Communicating the problems we're having. We haven't done that very well. Many outsiders see our work as very niche use cases, but these are important problems.


Vitalik: The economics / game theory / mechanism design space has a history and focus that aren't as focus to direct tinkering and engagement as cryptography and distributed systems. The idea that economic mechanisms are just something you can tinker with and deploy is starting to appear through centralized Web 2.0, ride-sharing platforms, but otherwise large portions of the space are doing highly theoretical mathematics, or arguing about the right marginal tax rate. But that's not true of the entire community, and we're increasingly getting better at finding the right kinds of people who are interested in problems they can solve for the blockchain community (and how blockchains can solve their problems).


Joseph: We're not at a place where a lot of traditional economic research is relevant. Mechanism design is an even more specific sub-discipline than microeconomics, and traditionally mechanism design research is primarily focused on auctions (50% or higher). If you apply a macroeconomist to view blockchains, they probably won't understand it very well. In engineering, distributed systems people pick up this stuff a lot faster than people who work on databases. BitTorrent is more analogous to blockchains than a SQL database. People who play videogames like MMORPGs, poker, MtGOW, or design them are people who understand the intersection of economics and design.


Joseph - When do channels make more sense than Plasma?


Joseph: When speed is critical, channels make sense. Plasma is good when something is okay to take longer than 5s in worst case.

Vitalik - you have been an outspoken critic of onchain governance. Why is there miner voting on gas limits in Ethereum?


Vitalik: There have been cases where the facts that in Ethereum, the gas limit is a setting that can be adjusted up and down by miners has saved us in multiple ways. During the DoS attack in 2016, the miners voted the gas limit down from 4.7M down to 1M which made the blockchain work safely in that period. We also had multiple capacity increases during the travails of hard forking. The reason why we did that was it was a suggestion by Andrew Miller back when Ethereum was being conceived. We thought about how to adjust the gas limit based on actual on-chain activity. All of the automated algorithms we could think about were gameable, but the most flexible approach was to just let miners vote on it.


Vitalik: Note, the gas limit is not a fundamental part of the Ethereum design. We also had no idea initially what the optimal gas limit should've been when we created Ethereum. Situations where there's a single number and it's not that bad if it goes up and down a bit over time, and you can benefit from responsiveness, and where there aren't too large incentives to shift it in the wrong direction, those are places where on-chain governance does make sense in limited forms. But applying miner voting to something like "should we try to rescue this wallet where Ether got stuck," this would be much more contentious and realistically, users want stronger guarantees.


Karl - Plasma XT, Plasma Unlimited, Plasma Cash, Plasma Debit, Plasma Cashflow, wtf?


Karl: The history of Plasma is interesting. Starts with the whitepaper, then iteration after iteration with Plasma MVP (exit vulnerabilities), then Plasma Cash (problems with fungible assets and transaction history growth), Plasma XT (addresses transaction history growth), Plasma Cashflow is now at the frontier which addresses fungibility and transaction history growth. It's been a wild ride of a bunch of Plasma researchers implementing a ton of research to make this into a full vision.


Joseph: There are a lot of constructions that each need names, and we're a little jokey about them. But these are all really research-phase iterations.


Joseph: Time is very interesting as a layer 2 problem. The creation of blocks is a kind of time-keeping mechanism. If you have certain requirements of stuff happening within a time window, that becomes a big challenge (synchrony assumptions). You see this in the real world too with courts, where something has to happen within a certain timeframe. Much of the original Plasma design had problems around time windows, but solving those problems introduces new time constraints. We're hopeful.


What is a topic in cryptoeconomics that you've changed your mind on in the last 12 months? (Anything changed your mind on twice?)


Karl: At first, I was incredibly bullish on the idea that a central operator in Plasma would put down a large deposit and then all transactions going through that operator, they could ensure that a user's transaction would be included (and if they lie, you can burn the operator's money). I'm excited for when blockchains can update UIs immediately. Then I realized, when these systems scale up, we have to really do analysis on the number of in-flight transactions at any given time, and how big do those bonds have to be and how much do users trust them? I didn't fully appreciate the complexity of capital lock-up costs, how many in-flight transactions (can't exceed the operator's bond). I've become more skeptical about this possibility.


Vitalik: I've been slowly getting more pessimistic about the original vision of DAOs. One of the primary arguments is that coming up with governance mechanisms that are horribly vulnerable to bribery and collusion and do something nontrivial is surprisingly difficult. I'm now more in favor of special-purpose, partial DAO-like mechanisms. One example is the DAICO mechanism I came up with earlier this year, which has ICO money being released to a smart contract and then users can vote on whether to release funds to the developer or shut down the entire enterprise. This combines together trust models such that both the developer and the majority of voters must be dishonest in some way. This combines security models in nice ways that has a failsafe.


Vitalik: As far as changing my mind twice, I'm now in favor of 99% PoS and 1% PoW, where 1% is that we should have bounties in-protocol to incentivize people to generate SNARKs and STARKs about protocol. Generating these proofs is complex enough that it seems like it should garner some kind of reward, and it seems very valuable for light clients of all kinds. Coming up with those kinds of gadgets seems possible 3-5 years down the road once ZK tech is more mature.


Joseph: The main thing I've changed my mind on is thinking P2P oracles was not that hard of a problem. I now think it does require much more research. Maybe you'll have someone propose things, a set of validators, etc. As an example, imagine you want someone to put up an incentivized wifi network. If the blockchain distributes tokens for doing this, how do you know whether someone's wifi is actually up and available? This requires P2P validation, and once you attach validation of action with economic incentives, there's a lot of ways to game this. It's enormously valuable to consumers though.


Karl: Do you think there'll be a general P2P oracle we can come up with, or will it be application-specific?


Joseph: Probably there will be a lot of commonality, and there will be something generally usable. Maybe 1 peron validates, then anyone can dispute, then it's adjudicated by a group of 10 people with the disputer putting up a bond. I think lots of research needs to happen here.


Karl: I always handwave here and say eventually we'll figure this out, but you're right, we do need more research here.


Joseph: It seems like a good 1/2 of all projects need this.


What's something that you have learned from each other?


Karl: From Vitalik, I've learned to be more rigorous about all the claims I make. Often the stuff I come up with is vague and I think it sorta works, but from talking with Vitalik I've learned to quantify the claims I make and apply more mathematical rigor: e.g., let's think about how many bytes will actually go over the network, or what are the security guarantees of this.


Vitalik: I feel like one thing I've come to appreciate is the value of our team doing a lot of traveling. It helps prevent a monoculture or getting caught in a whirlpool of confirmation bias. Because we spend so much time traveling, we engage with different intellectuals and come up with different ideas, and then once every couple of months come together and share ideas and have lively debates. This lets us grow in different directions and challenge each other more effectively than if we spent all of our time basically stewing in the same thoughts and opinions. That's helped a lot, for example, with Casper CBC and FFG learning a lot from each other, but also developing independently.