Just Enough Security for Cryptocurrencies
Itay Tsabary, Alexander Spiegelman, Ittay Eyal
If you know two things about cryptocurrencies like Bitcoin, one of them is probably that they expend power. A lot of power. Some estimates put the power consumption of those systems on par with countries like Austria and Colombia.
High power consumption is critical to the security of many cryptocurrencies: to compromise them an attacker would need to spend as much power as the rest of the system combined. And this mechanism works: major cryptocurrencies have demonstrated unprecedented resilience, despite no lack of incentive to violate their security and steal money.
But is the security threshold not exaggerated? Why is power consumption at the rate of Austria the right amount? Maybe half of that is sufficient? Or a quarter? Arguably, the adverse ecological effects of superfluous expenditure imply that we should target a lower expenditure rate, to achieve Just Enough Security.
We don’t know how much power is sufficient, this is a topic on its own. But until today there was no way to tune it. With existing protocols, cryptocurrency consumption is determined solely by the market powers, as follows. Cryptocurrencies increase their supply by minting new coins as a reward to miners — the participants that secure the system. The reward is a compensation for the miners’ resource expenditure, and the value of resources spent by all miners is about the same as the value of the minted coins. This amount of resources and tokens is a security threshold, as an attacker must invest just as much to manipulate the system.
Let us design a new system where the resource expenditure is 1/4. Here is a solution that doesn’t work: mint and reward only 1/4 coins compared to the original system. For example, if the original system rewarded 10 coins per action, the new system would reward 2.5 for the same action.
The original and the new systems have similar economic properties like money velocity, only the original has 4 times more circulating coins compared to the new system. That means each coin in the new system is worth 4 times as much as an original coin. Hence, participation rewards and consequently expenditures are the same in real terms.
We present two cryptocurrency protocols that allow their designer to reduce electricity consumption by an arbitrary factor, trading off security for ecological footprint. The full details including model refinement, the protocols, and game-theoretic analysis are in our technical report.
Through the rest of this text we’re going to compare our protocols against the classical Nakamoto protocol, which operates Bitcoin and similar systems including Bitcoin-Cash, Litecoin, ZCash, etc. We emphasize that the waste-reduction benefits apply with respect to any PoW cryptocurrency.
The first protocol, named PartialReward, reduces ecological damage by reducing the profit miners make. The intuition is rather simple — decrease mining rewards to decrease the profitability of resource consumption. It works as follows.
PartialReward mints coins at the same rate as in Nakamoto, hence each coin of the two systems has an equal value. However, in PartialReward miners get only a fraction of the minted coins, while the rest are distributed among all coin holders based on their relative coin holdings. Because the monetary value of mining block reward is lower, miners are motivated to expend less resources compared to the original system.
For implementation, allocating the miners’ rewards could be done as in any Nakamoto system. The rest of the coins can be allotted by an update of each clients’ balance. Alternatively, to avoid quantization issues, the amount can be granted via a lottery to a single client address.
While more environment friendly, PartialReward has an obvious downside — it reduces the costs required to create blocks. If the miner reward drops to x% compared to Nakamoto, the threshold for the attacker sizes drops by x%. We therefore seek another protocol that reduces consumption without the vulnerability predicament. Enter IncentivizedInternalExpenses.
Incentivized Internal Expenses
Our second protocol, IncentivizedInternalExpenses, is designed to have a reduced resource consumption while still maintaining high attack cost threshold. We’ll start by explaining the mechanism, and then review its security benefits.
The key idea is to maintain high block creation costs by incentivizing (not forcing!) the miners to spend some of their funds in a way internal to the system, as opposed to using them to pay for hardware and electricity. As in the original system and in PartialReward, it also mints coins at the same rate, maintaining an equal monetary value per coin.
We implement the internal spending mechanism by introducing a new property called score. Miners create blocks with score 1 by expending resources, as in Nakamoto. Alternatively, miners can create a block with score F > 1, where F is a system parameter. To create an F-score block, a miner must spend cryptocurrency coins internally in addition to the externally expended resources. The implication is that if she wants to create F-score blocks, the miner has less funds to spend on external resources. (we note that the consensus mechanism is the same as Nakamoto’s, it is indifferent to block scores)
The blockchain progresses in epochs of blocks, and the reward of each epoch is distributed at the epoch conclusion to all its blocks. The total amount rewarded is the same as in Nakamoto. However, each block is rewarded according to its score ratio out of all scores in the epoch.
To maintain the same value of the cryptocurrency, internally-spent coins are kept in circulation, and redistributed to all system users based on their relative coin holdings, as in PartialReward.
Intuitively, setting a sufficiently-high factored-blocks score incentivizes miners to spend internally, reducing their external spending. Indeed we show this is the case using both analytical and numerical evaluation.
To discuss the security benefits of IncentivizedInternalExpenses, we need to refine the security definition of attack cost. Say an attacker wants to re-write history, canceling her past payments for an already-delivered Lamborghini. To do so she would have to create an alternative blockchain branch, incurring the block creation costs. However, once succeeded, she also receives block rewards for her created blocks, making the attack cost zero. Therefore, the correct measure is the upfront costs necessary to perform such attacks.
In IncentivizedInternalExpenses an attacker has two paths. The first is to create F-score blocks on her alternative chain, incurring the same costs as the rest of the miners and requiring the same resource threshold. In this path a successful attack is, as in Nakamoto, free. Alternatively, the attacker can go for creating solely regular blocks; she can then use all her funds for external resources, creating blocks faster and incurring a lower cost. However, in this path she will not get fully compensated for her expenditures when the attack succeeds. For a sufficiently large F, this is not an appealing option (unless car prices greatly surpass the replaced block rewards, but the required confirmation time should account for that).
Note that IncentivizedInternalExpenses introduces another trade-off. If miners are required to obtain coins to effectively participate, they in some sense relying upon the permission of existing coin holders to participate. If they don’t have that permission, their mining efforts will be less efficient (they can only produce 1-score blocks), resulting in lower expected rewards. In other words, the system is not as permissionless as Nakamoto’s blockchain, though it is more permissionless than proof of stake systems.
To conclude, balancing system security and ecological damage is an important step in widening the usability of cryptocurrency systems. We introduce two blockchain protocols that achieve reduced ecological footprint compared to existing protocols. They allow, for the first time, for cryptocurrency blockchain designers to tune the ecological footprint of their blockchains.
The full details are in our technical report.
We thanks Sarah Allen for her help in compiling this text.