An Elegant MESS— The Fast Solution to 51% attacks and Low Hash Rate
ETC Core, in consultancy with OpenRelay and ChainSafe, have developed and proposed a finality algorithm, called MESS, for Ethereum Classic
Hitting Hackers at their wallets
MESS is a solution that would make attacking the chain 31x more expensive than it currently is. Want to do a re-org 3000 blocks deep? You could purchase the hashrate on NiceHash.
Protected by MESS, that would now cost over $20,000,000.
Not only would that make virtually any attack unprofitable, but even using NiceHash, this amount of hashrate is simply not available.
This change comes at a very critical juncture for Ethereum Classic.
“MESS will enable exchanges to safely reduce confirmation times and ensure that miners will not lose block rewards; stabilizing the network and allowing it to return to growth,” said James Wo Founder and Chairman of ETC Labs.
When will MESS be available and active?
Unlike other proposed solutions, MESS can be rolled out without any hardforks and with minimal implementation time. This week a dedicated test network of 150 nodes is running simulations of different potential attacks.
The implementation is complete and proposed at Core-Geth. It will be very important that as many nodes as possible are using a MESS-protected node client so that the entire network can be super secure.
Modified Exponential Subjective Scoring (MESS)
Nodes achieve an objective network consensus by following one rule: the heaviest chain wins. Regardless of the nodes hardware, location, and network connectivity; if they all follow that one rule, they will almost always reach consensus.
First proposed by Vitalik in 2014, MESS changes this rule so nodes will prefer chain segments they see first over segments they see later.
The key principle: Large reorganizations(reorgs) are usually bad, small reorganizations are usually good. If the preferred chain is the first one the node sees, building a super long chain in secret is no longer an attack vector.
Blockchain networks constantly have healthy small reorgs as nodes are updating state based on new information. Large reorgs, however, to date, have been against Ethereum Classic’s moral code. The DAO hack is the most famous example of this, where Ethereum rolled back time with a large reorg. Binance’s CZ also suggested doing the same after a Binance hack.
In both instances, those decisions would violate ETC’s one mantra “code is law.”
This small, yet powerful change, is what makes attacking exponentially more expensive while staying true to ETC’s identity.
“While developing a solution for ETC, it was important to us that it be low or no impact on existing consensus or sealing rules, concise enough to implement and test quickly, but comprehensively, and not likely to cause damage or expose the network to risks that could potentially outweigh its benefits,” said Isaac A., ETC Core Protocol Lead and Client Developer.
Choosing MESS
The route to developing MESS wasn’t clear from the beginning.
Isaac A. said
“ After about a month of some seriously sleepless nights and one or two new gray hairs” the ETC Core team, and the developers at ChainSafe and OpenRelay chose MESS from an exhaustive list of proposed solutions.
We’ve considered and developed an exhaustive (or at least exhausting!) set of options including existing or externally proposed options like PirlGuard, VeriBlock, block sealing algorithm modifications, and various checkpointing solutions; and have designed and evaluated our own solutions including changes to the monetary policy, systems we called Permapointing and Flashpointing, a dynamic probability-based reorg acceptance algorithm we called Continuously Probable Reorganizations, and a solution using what we called Endorser Transactions that democratized chain preference publication and observation.
All of our work will eventually be made public with the hope that our designs and experiments, though imperfect, may add some value to the larger domain of public distributed systems research.
In developing a solution for ETC it was important to us that it be:
Low or no impact on existing consensus or sealing rules. This mitigates risk that may otherwise be assumed, both in the theoretical scope as well as that of implementation complexity.
Concise enough to implement and test quickly and comprehensively. Urgency is a priority, and in order to achieve something reliable it should avoid undue complexity if possible.
Not likely to cause damage or expose the network to risk outweighing its benefit. Solutions having reasonably achievable exploits would replace one weakness with another.
You can read the full post by Isaac. A here
Status and Next Steps
The specification is under review and discussion at Ethereum Classic’s Improvement Proposals repository, here. We encourage you to review it yourself and join the conversation.
Core-Geth has published a “Pre-Release” activating the feature on Ethereum Classic’s Mordor testnet, and for nodes that have upgraded there, it will be live now. All are welcome to help test this public network.
Testing has begun and will continue through the week on the dedicated “MESSNet” testnet, and we’ll provide a summary of tests and their results once that’s complete.
For background on earlier, related considerations of finality in this context, please find these earlier documents:
