The Nexus blockchain is still in the design stage, but we want to share some ideas about our vision for what the L1 could be.
An advantage we have at Nexus is that we’re already deep into verifiable computation. So we can prove a blockchain is correctly computed at a low cost to anybody who wants to verify it.
However, because the blockchain we are building is both open source and permissionless, we need to think about forking. If you think about a blockchain like a railway system, a fork can be compared to a switch in the track. Sometimes forks are good, a softfork or hardfork may be used to switch to a new improved blockchain protocol. But untended switches should be avoided, a malicious fork can for instance be used to launch a double spending attack.
Verifiable computation by itself does not protect against forking, but it makes sense to pair strong correctness guarantees with strong protection against forks. Overall we want to make the Nexus Layer 1 as robust as possible.
This post is about how we think about incentives and punishment for misbehavior to guard against forking attacks. The TLDR is that each validator node will put in some stake and risk having it slashed if it misbehaves by creating or supporting a fork.
Fortunately, if there is ever a fork it will be easy to see who has created the fork and who supported it. Budish et al. showed that if more than ⅓ of the stake is well-behaved (the blockchain has not collapsed) it is possible to detect and punish misbehaving parties to a sufficient degree to disincentivize malicious forks.
We analyze their Expensive-to-Attack Absent Collapse (EAAC) framework to derive the economic throughput the blockchain system can support in a given time window while still disincentivizing forks. Moreover, we propose mechanisms that can increase the economic throughput to get maximal economic benefit of the locked up stake.
Usually an economic security analysis aims to find the minimal cost or expense of an attack that could create a fork.
Frequently these reports say little about how to constrain blockchain activity to remain below the cost range of an attack such that an attacker will not want to pay the cost of an attack. This is understandable, the main value of the fork can be in the application layer and be invisible to the consensus layer making it hard to analyze.
We propose that users can make the value to protect explicit in their transactions. Specifically, if a fork is detected and a branch is discarded we propose compensating the receivers for the value they should have received.
By compensating receivers, we make the blockchain more protective and safe for users, which encourages adoption. If you have a transaction you really care about, you can now signal the value you place on it to the blockchain by adding an extra payment to yourself. If your transaction gets included in a fork during an attack and is later discarded, you now get compensation for the trouble it may cause you.
The added payment to yourself can be seen as a way to buy insurance, an insurance that signals to the system the real value of your transaction. Note that paying yourself extra as an insurance against forks may not be free. Your added payment makes the transaction higher value, and it would be reasonable that higher value transactions demand higher fees because they occupy a bigger share of the blockchain’s economic throughput capacity.
Byzantine Fault Tolerance and forking attacks
Two core security properties of consensus protocols used in blockchains are
Safety: the blockchain does not fork (it should also be correct, but this is easy to get)
Liveness: the blockchain continues to make progress
Most proof-of-stake (PoS) blockchains lean on a familiar pillar: if more than ⅔ of the stake (or voting weight) signs a block, the network treats that block as final. The reason the threshold is ⅔ is that it simultaneously ensures both safety and liveness. Specifically, if less than ⅓ of the stake is misbehaving, there will be no malicious forks and the blockchain will continue to make progress. Here’s an illustration of a safe and live blockchain, where blocks continue to be added one after another.
What happens if more than ⅓ of the stake is corrupt? Well, one problem is that we cannot guarantee liveness any more. If more than ⅓ of the stake withholds signatures we cannot reach the ⅔ threshold and finalize blocks. But more alarming is the safety risk, there may be forks where two branches both pass the ⅔ signature threshold.
The problem with forks is that they may facilitate double spending attacks. Eve can make a transaction paying Alice for a car (included in block B), and a transaction using the same money to pay Bob for a boat in a different branch (included in block B’).
Now Eve gets both a car and a boat for the price of one, and eventually when the fork is discovered Alice and Bob are left with the mess of who gets to keep the payment. Of course the more the blockchain forks, the more Eve can spend.
Accountability and economic security
What can we do to prevent fork attacks? If the attacker controls more than ⅔ of the stake, there is not much to do, she can create numerous forks and splurge in a multi-spending spree. We therefore say the blockchain has collapsed if more than ⅔ of the stake is willing to coordinate around a fork.
Absent collapse, we may hope to defend against forks when the attacker controls less than ⅔ of the stake though. We will now describe the intuition behind such mitigations, which are used in Ethereum PoS and formally studied by Budish, Lewis-Pye and Roughgarden who define the notion of Expensive-to-Attack Absent Collapse (EAAC).
The idea is that while we only fully prevent forks and get a strong safety guarantee when the attacker controls less than ⅓ of the stake, we can still disincentivize forks when the attacker controls less than ⅔ of the stake. This is enforced through punishment, if the attacker creates a fork, the blockchain system can punish the offenders by slashing their stake thus making it more costly to fork.
The first step in designing a punishment system is to consider how to detect malicious behavior. Fortunately, most consensus protocols provide accountability. Even if an attacker controls 100% of the stake, if she creates a fork we have strong evidence of misbehavior.
Specifically, to create a fork there must be some of the stake that supports two or more branches. Honest stakers should only sign one branch. But for two branches to both reach support by more than ⅔ of the stake, there must be at least some of the stake that has supported blocks in distinct branches.
The attacker has therefore signed its own admission of guilt, the conflicting signatures and blocks in the fork constitute evidence against equivocating stake. Given such evidence, the blockchain can then slash the offender (confiscate their stake) and burn or redistribute the stake controlled by the malicious actor.
When we detect a guilty party we will slash their stake. Consider for simplicity an example where the stake is split into four quarters (which we assume will not be subdivided).
If the attacker controls two quarters, it has ½ the total stake and it may create a fork with two branches. The honest stakers will support at most one branch though, so to exceed the threshold of ⅔ stake in both branches the attacker needs to double vote for both branches with its own quarters and nudge the two honest quarters to support separate branches, i.e., the attacker is making its own ½ of the total stake slashable.
This gives a degree of economic security, it only makes sense for the attacker to fork if the gain exceeds half the total stake.
Suppose the attacker can create a fork with two branches that after a few blocks each are detected and mitigated as illustrated above.
So instead of solely continuing with the legal branch the attacker creates an extra branch and double spends, extracting additional values v2’, v3’, v4’ within the detection window. This is unprofitable to the attacker as long as v2’+v3’+v4’ < ½ total stake.
Economic throughput
Another way of looking at economic security is to view blockchain as having an economic throughput capacity that it can support per block.
Take the simplest case with at most two branches, an attacker controlling more than ⅓ of the total stake may be able to create a two-branch fork, but has to sacrifice at least ⅓ of the total stake(s) to slashing.
Say we have a block at height h, from which the attacker tries to fork and create two branches. Now if there is a detection window of d blocks within which the honest nodes would detect and slash the attacker, this means the attacker may double spend v_{h+1}+...+v_{h+d} in the extra branch.
Let’s say the maximal value the attacker can extract per block is v. Then this is unprofitable to the attacker when dv < ⅓ s. In other words, the economic throughput we can support per block is v < s/(3d).
Here’s an example: The total stake is 3M USD, we expect a finalization time of 1 second per block but set the detection window to 100 seconds ~ 100 blocks, in expectation that by this time all honest nodes have heard from each other and thus detected a fork. The economic throughput bound is s/3d = 3M USD / 300 = 10K USD per block. This means that if the adversary cannot spend more than 10K per block she will be disincentivized to create a fork where this branch will later be detected and discarded.
The reader may have guessed that if there are more forks, the attacker may have higher gains due to multi-spending. This is indeed the case, to disincentivize forking with b branches, the economic throughput per block should be v < s / (3(b-1)d).
Increasing the economic throughput through above threshold confirmations
We want each staked token to contribute maximally to increase the economic security, so is there a way to increase the economic throughput capacity? In the blockchain literature finalization when we get confirmation from more than ⅔ of the total stake is usually the end of the story.
But if we can keep adding confirmations after a block has already been finalizes and go beyond the ⅔ threshold, we may increase the economic security and throughput. Of course we cannot guarantee all nodes to be responsive, an attacker who controls some of the stake could withhold confirmations.
But if things are running smoothly (and if we incentivize contributions) we may imagine a system where we usually get close to 100% confirmations.
Going beyond ⅔ of the total stake confirming a block, let us imagine we have c > ⅔ of the total stake, s, confirming a block. If there is a fork, this means the attacker has reached cs stake in one branch and ⅔s stake in the other branch, meaning there must be (c+⅔-1)s stake that is equivocating. This gives us (c-⅓)s > ⅓ s stake that is slashable, so we have increased economic security.
If each finalized block has confirmations from c-⅓ of the total stake, the economic throughput capacity per block is v < s(c-⅓)/((b-1)d). But we don’t even need the last blocks to be confirmed to this high a degree, it suffices that some of the blocks within the detection window have higher confirmation degree. Consider blocks with confirmation degrees c1 ≥ c2 ≥ …≥ c_d ≥ ⅔ and content values v1, v2,...,v_d. To disincentivize attacks, we need v_d < (c_d-⅓), v_{d-1}+v_d < c_{d-1},... This shows we can get high throughout even when the tail is only lightly protected. Example: d = 100, c1=...=c_{d/2}=c, c_{d/2+1}=...=c_d=⅔.
We still get a block throughput capacity of v < s(c-⅓)/((b-1)d).
It is worth noting that absent collapse, extra confirmations can give even higher assurance. For instance, if we know max ½ the stake will be willing to coordinate to fork, the attacker can at most fork into two branches. But if we allow additional confirmations and see a block with ⅚ confirmations, this actually means no fork can happen. Under the assumption that max ½ of the stake is willing to equivocate, this means there is no forking up to this block. This has been discussed in the Ethereum community under the notion of weak subjectivity; once we have a block that is sufficiently confirmed we can consider it so strongly confirmed that we treat it as a new genesis block.
Transaction valuation
We have analyzed the economic throughput capacity in terms of the value we can sustain per block while disincentivizing a fork. But how can the stake controllers know what the value of the transactions in the block are and whether it makes sense to confirm or is too risky?
In blockchains aimed solely at financial transfers from one account to another, they may sum up the amounts to get a total transaction value for the block. However, in a blockchain with a rich application layer the main value to the end users may be very different from nominal transaction values. Moreover, the attacker’s valuation of a double spend may also be different from the user’s perspective, especially if the attacker can combine the double spend with external leverage.
Instead of tackling the question directly, we are approaching valuation indirectly and asking a different question first.
When a fork is discovered, what should happen? Merging branches may not make sense, transactions can depend on previous blocks (indeed making transactions depend on context is good security practice, it protects the user against having her transaction repurposed at times she did not intend it to happen).
So the natural answer is to keep one branch and discard the other(s). Who loses when a branch is discarded? Arguably, the users most at risk of losing out are the recipients, if Alice bought a car from Bob, but the payment is discarded, then Bob suffers. And how can the attacker win from having a branch discarded, via double spending such that the recipients do not get the payment they expected. As a user protection mechanism, we therefore propose to use the slashed stake as compensation to the recipients.
This converts the question of value in the blocks to a question of what is a reasonable customer satisfaction guarantee.
There are details to work out to fully bake the idea of using a slashed stake to pay out compensation. There should be enough left over to incentivize the other stakers to act on evidence and slash equivocating nodes. Also, Nexus blockchain will support smart contracts, so they need to provide an entry point to receive compensation since it will not be quite the same as a normal transaction and invocation.
Taking the idea of compensation to the next level, let’s look at it from the sender’s perspective. Their reason for sending a transaction is that they will gain more value. For example, Alice is buying a car from Bob because the car is more valuable to her than the amount she is paying.
So if the branch with her transaction is discarded Bob may decide to stop the trade and sell the car to somebody else. So Alice may also be in need of customer protection. Fortunately, she can buy herself insurance. Alice sends a transaction that pays Bob for the car, and also pays an amount to herself. Now, if the branch is discarded, she is also a recipient and will receive compensation. So she has bought herself insurance.
At first glance it may seem like the insurance is free. But we expect it to be a paid service. We have not discussed the fees users pay. But if Alice increases the value of a transaction by paying herself an amount, she is consuming a larger share of the block’s economic throughput capacity.
Accordingly, the nodes running the blockchain will need to receive a higher transaction fee.
