Introduction to Blockchain through Cryptoeconomics — Part 1: Bitcoin
Zubin “zk” Koticha is Head of Research and Development at Blockchain at Berkeley, where he leads the Cryptoeconomics research team. His team are grant recipients of Berkeley SCET Blockchain Lab’s first award cycle. They conduct research with Professors Elaine Shi at Thunder and Gireeja Ranade, and has ongoing projects with industry. His team was a finalist at the Ethereal Hackathon and the World Cryptoeconomic Forum for their research.
This is part one of a series about the cryptoeconomic incentive systems that underlie different blockchain protocols and emerging research questions in the blockchain technology space. You can find part 2 here.
Section 1: Bitcoin as an Economics Experiment
The advent of Bitcoin (BTC) presents compelling questions to the fields of cryptography, game theory, distributed systems, and microeconomics. Though BTC is often touted as a major technological breakthrough, none of the technology itself that comprises its protocol (like the cryptographic techniques or the idea of Proof of Work) was invented by Satoshi Nakamoto, Bitcoin’s pseudonymous creator. Most of these technologies had existed for decades prior to their inclusion in the BTC protocol.
Instead, Bitcoin’s brilliance emerges from its economic design. It has the ability to unite disparate actors, 1. none of whom trust each other, 2. all of whom have an incentive to steal from each other, and 3. some of whom hope to destroy the system. It aligns these adversaries’ incentives such that they can come together to create a single, working, growing, indestructible ledger that remains open and transparent to all. The puzzle of creating such a system was fundamentally difficult and thus remained unsolved until 2009.
A functioning currency system not owned by any government, Bitcoin has had outsized success as an experiment in game theory and economics. Therefore, although Bitcoin’s protocol is often explained from a technological point of view, in this series, I will convey the incentives existing at every level that allow for its various comprising parties to interact with cohesion and security. This study of the incentives that secure blockchain systems is known as cryptoeconomics.
Section 2: Transactions and Fees
In a monetary system, we must log account balances and transactions (a list of which is known as a ledger), which can be accomplished with a database. Since we don’t want our currency, and therefore our database, to be owned and controlled by a single party, the computers which comprise this database must be distributed and managed in a decentralized fashion. Thus, we utilize a distributed ledger. We imagine many computers, owned by different parties, all trying to come to consensus on the same version of the ledger (to have the same account balances for all participants, etc.).
The most important use of a currency system is for transactions. Advancements in cryptography — a subfield of computer science — ensure that only those who possess funds can send them, and that only the intended recipients receive them, while keeping both the sender and the recipient anonymous. This is done through cryptographic keys, one public (like a username) and one private (a password) that cannot be linked to their real-world owner. These security techniques, called asymmetric key cryptography, are so strong that they cannot be defrauded and are the security support structure of the modern internet.
The use of cryptography is why Bitcoin and its relatives are called cryptocurrencies!
This system as discussed thus far contains a distributed set of computers holding and continuously syncing a shared database, as well as transactors who can send and receive money securely. These distributed computers must be actively listening for messages from accounts that are trying to establish a valid transaction so that they don’t miss anyone trying to send money.
The first game theoretic problem we run into is the one of asymmetric costs; transactions are trivial and costless for the transactor, but expensive for the network. Every transaction has a large impact on the network, since it must be relayed to every single computer which is keeping track of the network (you can imagine that in Bitcoin, there are many such computers, called “nodes”).
Section 3: Denial of Service from Transactors
As mentioned, transactions are very easy to produce; if an attacker had 1 BTC, she could create 10,000,000 transactions, each sending .0000001 BTC. These 10,000,000 transactions would at best slow down the network for everyone else, and, at worse, stall it completely. This is known as a Denial of Service (DoS) attack.
Worse still, given that we want to preserve anonymity, we do not know the identity of the sender or the recipient; the sender could just be sending all these transactions from one of their accounts to another of their accounts (called a Sybil attack).
In order for transactors to properly compensate the network for the costs they create, we introduce transaction fees. These fees are specified by the transaction sender. This makes it prohibitively expensive for transactors to introduce an arbitrarily high number of transactions to the blockchain.
Section 4: Building Blocks (pun intended)
Now, given that there is no centralized party which controls the database, who should be responsible for its upkeep? Who will aggregate new transactions and publish them to the blockchain?
Those people — whom we call miners — update the network, and we pay them new BTC every time they do so. First, they receive transaction fees from money senders. Second, all nodes connected to the blockchain agree that the protocol should mint new Bitcoin and send it to miners who mine new blocks. These new BTC are paid to miners in “coinbase” transactions, which is how new the BTC money supply is increased. Miners are therefore paid for the work they do.
Miners “listen” for transactions on the network and they gather these transactions into what we call a block. Miners choose to put the transactions that pay out the highest transaction fees into each block, and they “chain” this block on to the previous set of transactions (thus it’s called a blockchain!).
Section 5: Denial of Service from Miners
Unfortunately, we’ve just created an adverse cryptoeconomic incentive for rational miners to DoS attack the system. Miners would publish an infinite number of blocks to the network, like empty blocks, in order to maximize their gains. Even if we prohibit the inclusion of empty blocks, the miner can load up an infinite amount of blocks with phony Sybil transactions to their own accounts. Since transaction fees would be paid to themselves, they would incur no cost in carrying out such an attack.
Miners can only include a certain number of transactions in their block, so they only include blocks where the senders have proposed sufficiently high transaction fees. Thus, transactors are incentivized to pay a fair price for their transactions. Higher transaction fees increase the likelihood that the transaction will be included in the next block. The idea is that in the long run, an equilibrium will be established whereby the average transaction fee (the marginal cost of a transaction) and the costs on the network (memory, CPU cycles, electricity, network usage) will become equal (interestingly, we’ve effectively created the first decentralized, free market for compute time). It also incentivizes miners to include full blocks.
As discussed previously, we must disincentivize miners from spamming the network, making it difficult for them to DoS it. But this is problematic. How can we incentivize miners to update the network, while also disincentivize them from updating the network too often (aka spamming)? We have this same asymmetry as before; miners impose costs on the system since their new blocks must be replicated to every single node, but they incur very little cost in making transactions. How can we solve this asymmetry problem so that miners are incentivized both to add to the blockchain, but not spam it?
Part 6: Solving the Asymmetry of Costs Problem
4 solutions (amongst others) have been proposed:
- Only have trusted miners — ones that the network agrees are unlikely to act subversively. This is the model that Ripple and Stellar follow.
- Make it difficult and costly to include a new block. This is the idea of Proof of Work, and it is used by Bitcoin and most other public blockchains today.
- Limit the number of blocks any miner is allowed to mine. Since miners can create multiple Sybil addresses and thus pretend like every block is their first mined, enforcing such a limit is only possible if the network keeps track of the public ID associated with each miner’s address.
- Create trust through incentives, i.e. a system where there are severe punishments for DoS attacks and other misbehavior, and rewards for honest behavior.
In the next blog post, we will elaborate on the above and dig into Bitcoin network’s solution: the concept of Proof of Work. Proof of Work (PoW) is comprised of algorithmic puzzles which make it costly — in terms of electricity, CPU cycles, costs of equipment, and time — to add a block to the blockchain.
A special thanks to Alexis Gauba, Maaz Uddin, Dev Ojha, Steven Elleman, Melissa Mokhtari, and Ashley Lannquist who all suggested edits to this post before its publishing.
