Skip to content

cheat-sheets/cryptoeconomics-cheat-sheet

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

16 Commits
 
 

Repository files navigation

Cryptoeconomics Cheat Sheet

Cryptoeconomics - generalized field that deals with large class of systems that try to use both cryptographic tools and economic incentives defined in the system in order to achieve information security goals of that system. (Vitalik Buterin)

  • cryptography can prove properties about messages that happened in the past.
  • economic incentives can encourage desired properties to hold into the future.

Cryptoeconomics (alternative definition) - the application of incentive mechanism design to information security problems (Vlad Zamfir).

Table of Contents


Related Fields

Cryptography

  • Hashes
  • Signatures
  • ZKPs
  • PoW
  • Erasure Codes
  • Timelock crypto / sequential PoW
  • Homomorphic encryption / obfuscation

Economy

Incentives:

  • rewards/penalties
  • privileges

Game Theory / Mechanism Design

Distributed Systems


Concepts

Cryptoeconomic resource - a resource, possession of which gives agents the right to collectively perform state transitions in the cryptoeconomic system. E.g. hashing power, stake, tokens.

Cryptoeconomic set - all agents possessing the cryptoeconomic resource.

Cryptoeconomic Security Margin - a fraction of cryptoeconomic resource X such that you can prove "either a given guarantee G is satisfied or those at fault for violating G are poorer than they otherwise would have been by at least X fraction of the cryptoeconomic resource". E.g. security margin of 0.5 means that it costs the attacker half of all hashing power to violate the guarantee G.

Cryptoeconomic proof - a message signed by an actor that can be interpreted as "I certify that either P is true, or I suffer an economic loss of size X".


Assumptions

The basic security assumptions that cryptoeconomics depends on are the following:

  1. No set of individuals that control more than 25% of all computational resources is capable of colluding.
  2. No set of individuals that control more than 25% of all money is capable of colluding.
  3. The amount of computation of a certain proof of work function that can be accomplished with a given amount of money is not superlinear beyond a point which is reasonably low.
  4. There exists a non-negligible number of altruists and a non-negligible number of crazies or political opponents of the system, and the majority of users can be reasonably modeled as being close to economically rational.
  5. The number of users of a system is large, and users can appear or disappear at any time, although at least some users are persistent.
  6. Censorship is impossible, and any two nodes can send messages to each other relatively quickly.
  7. It is trivial to generate a very large number of IP addresses, and one can purchase an unlimited amount of network bandwidth.
  8. Many users are anonymous, so negative reputations and debts are close to unenforceable.

Security Models

Security models are different in the assumptions that they make about the real world. It's not clear what assumptions are more realistic, nevertheless it's useful to perform analysis in different models to have the clearer picture about the security of a system.

Different security models give different security margins.

  • Honest Majority - assumes that up to X (usually a number less that 1/2) of agents are controlled by an attacker, and the remaining agents honestly follow the protocol.

    • Tranditional Fault Tolerance - assumes almost all agents are honest (X is close to 0).
    • Bysantine Fault Tolerance - assumes up to 1/3 of agents are controlled by an attacker.
  • Uncoordinated Majority - assumes that up to X (often between 1/4 and 1/2) of agents are capable of coordinating their actions, all agents are rational in a game-theoretic sense.

    • model parameter - level of coordination X.
  • Coordinated Majority - assumes that all agents are controlled by the same actor, or are fully capable of coordinating on the economically optimal choice between themselves. We can talk about the cost to the coalition (or profit to the coalition) of achieving some undesirable outcome.

    • model parameter - level of coordination X (close to 1).
  • Bribing Attacker - takes the uncoordinated majority model, but instead of making the attacker be one of the participants, the attacker sits outside the protocol, and has the ability to bribe any participants to change their behavior. Attackers are modeled as having a budget, which is the maximum that they are willing to pay, and we can talk about their cost, the amount that they end up paying to disrupt the protocol equilibrium.

    • model parameter - attacker's budget B.

Bitcoin with selfish mining fix analysis:

Guarantee G: there is no double spending.

Model Parameters Security Margin
Honest Majority ~0.5 (51% attack)
Uncoordinated Majority Level of coordination ~0.5 ~0.25 (selfish mining attack)*
Coordinated Majority Level of coordination ~1 0
Bribing Attacker Budget > 13.2 * number_of_blocks ~0

* Without the selfish mining fix the security margin in uncoordinated majority model is epsilon (slightly greater than 0).

Shelling coin analysis:

Guarantee G: the result of voting represents the reality.

Model Parameters Security Margin
Honest Majority 0.5 (51% attack)
Uncoordinated Majority Level of coordination ~0.5 ~0.25 **
Coordinated Majority Level of coordination ~1 0
Bribing Attacker Budget > 0.5 ~0

** The attacker only needs to possess slightly more than half of the coordinated part of the economic set. The other half has the incentive to vote with the attacker.


Cryptoeconomic Systems

Random Number Generation

A number of protocols, including consensus protocols, blockchain-based lotteries, scalable sampling schemes, etc, require some kind of random number generation in the protocol. There are a number of alternatives with their pros and cons:

  • PoW - use block hash
  • N-of-N commit-reveal (RANDAO)
  • Oracles
  • Timelock crypto

Resources

Releases

No releases published

Packages

No packages published