Spencer Noon
Originally published on Medium on April 11, 2018
The Persistent Forker is an annoying but effective attack vector against tokens, and it’s something that I believe will be employed broadly across the sector in the future. Here’s how the attack works, straight from the mouth of a fictional attacker:
“My company relies on Protocol X. In order to use Protocol X, users need to hold PRX tokens as “gas” for the network, which we believe introduces unnecessary friction to our user experience. Because of this, we’ve decided to employ a developer whose only job is to monitor the Protocol X codebase (which is open source and transparent) and fork out the PRX token every time an update is made. This allows us to always run the latest version of the software with the added benefit of being able to provide a better user experience for our users since there’s no token.”
Something similar already happens in the wild today as many altcoin developers actively do this with the Bitcoin Core repo since their own codebases are largely carbon copies of Bitcoin. It only takes one developer on the job to keep the forked codebase updated at all times.
So will the Persistent Forker be responsible for the destruction of millions or billions of dollars in network value in the future as investors lose confidence in many tokens?
Introducing Protocol Defense
In some cases — yes, but there are a number of different defense mechanisms that networks can potentially employ to combat the Persistent Forker. We’ll explore them below.
Increase the Code Complexity
If you go back to our fictional example, it only takes one developer to monitor Protocol X’s codebase and continuously fork out the token. If an above-average developer makes ~$125,000 per year, a business that generates decent revenues could easily afford to hire that person and still have a profitable business.
But — if Protocol X wanted — they could purposefully make their code more complex, perhaps even drastically changing it up with each release. This cat and mouse game would make it harder to persistently fork their codebase, and the attacking company would likely have to employ additional developers to continue operations.
Verdict: Bad idea
This strategy may defeat smaller Persistent Forkers, but it will likely fail against businesses that can afford to employ multiple developers. More importantly, adding unnecessary complexity to code is never a good idea.
Patent Your Code
Protocol X could patent their code and pursue legal action against the Persistent Forker! If that sounds like a ridiculous idea, you’d be correct, but this one actually has real-world precedent — Hedera Hashgraph will soon allow users to view their code but not allow them to modify or redistribute it legally.
Verdict: Really bad idea
Using a patent completely violates the ethos of decentralized networks, and it is not clear that a legal defense strategy for blockchains is even viable.
Ignore the Fork
Could Protocol X just ignore the Persistent Forker? It would signal to the market that they don’t consider the fork to be competitive, which may instill confidence in PRX token holders. They could even make the argument that all forks are complementary and additive to the system as a whole (which I’ve seen some project leaders do today).
The strategy of ignoring has precedent in the tech world, where category winners such as Facebook and Google are challenged by startups constantly. The challenger is ignored at first, but if they become big enough they are eventually dealt with in some way (such as being acquired). Crypto networks could employ a similar strategy of only dealing with forkers who gain sufficient traction.
Verdict: Ultimately a bad idea
Ignoring the Persistent Forker may work for a while since the market is still in its infancy. However, unlike big tech companies, protocols do not have major moats around their businesses. Ignoring a challenger network for a while might be completely rational, but waiting until it’s too late could be catastrophic. It is better to be on the offensive.
Build a Black Box
What if crypto networks didn’t open source all of their code? They could place a small but critical portion of it in a “black box” that was somehow deemed safe — this would likely entail a trusted setup plus cryptographically proving that the code inside the black box didn’t change over time — to make it impossible to fork a working version of the network.
Old-school crypto folks (including myself) are shaking their heads right now since this strategy violates many of our core principles (e.g. trusted 3rd parties don’t exist) but I’m mentioning it because there are plenty of projects with huge market caps that are doing this today for reasons other than defense (e.g. their code is just not ready). I actually think it will be employed even more in the future.
There is also an argument to be made that having 100% open-source code isn’t necessary for all decentralized networks — especially those that are not trying to be a store of value.
Verdict: Potentially viable
I’m not a fan of this approach, but it probably warrants further exploration by the technical community. If done right, a black box could potentially be used by some projects under the right circumstances.
Design the Right Token Incentives
Which leads us to the last line of defense — the most viable way to stop the Persistent Forker is to create better incentives around using your token in the first place.
For starters, one universal incentive that all crypto networks have is the ability to grant robust governance rights to token holders. This allows token holders to have a direct say in how the network is built and maintained, which could theoretically incentivize potential forkers to stay on the network since they’ll want to influence future decisions.
Another incentive that is extremely difficult to implement but very powerful if done right is to create a network effect/shared benefit in using the token that simply can’t be realized in the forked network. The 0x Project is doing this today — while it is possible to fork out the ZRX token to reduce customer friction, relayers who do this cannot access the shared liquidity pool from the rest of the network. This incentive will become even stickier as more relayers join the network and share their order books in the future.
Verdict: Good idea
It remains to be seen whether governance itself will provide a big enough incentive to keep stakeholders on a network long term (it’s got a better shot if the network supports tens of millions of people, in my opinion). However, creating a unique network effect/shared benefit of using a token is an extremely viable strategy to defeat the Persistent Forker over the long term. With that said, it may not be possible for all networks to create this incentive.
Conclusion
In the coming months and years, the Persistent Forker will rear its head and challenge numerous token networks, causing many of us to evaluate what these tokens are really worth in the first place. The networks that can fight back and properly defend themselves against this attack will continue to maintain their token’s value, and the ones that cannot should expect to see their network values crater over time.
Welcome to Crypto Darwinism — where only the strongest protocols survive.
**