Define a function arbitrating chain acceptance using relative total difficulty and common ancestor time to raise finality confidence.
A low hashrate has caused Ethereum Classic’s consensus algorithms to yield inconvenient and undesirable finality rates.
This proposal offers a way to increase the finality rate without tampering with existing “hard” chain consensus functions or characteristics, and to do so with minimal negative side effects.
This proposal is built on a proposed core principle to Ethereum Classic neatly summed as:
Small reorgs are normal and healthy; large reorgs are suspicious. Given a reorg of unusual length, nodes should value their local (first-available) segment with preference over the later proposed segment, despite that it may have greater difficulty. Source
What follows is an algorithm and implementation details toward a way to realize this opinion programmatically as convention for network clients.
This is a modified (M) version of Buterin’s Exponential Subjective Scoring (ESS) by
See References for what I’ve found on the topic.
The Case and Place of Subjectivity
This specification maintains the (modified) GHOST protocol as an invariant; existing consensus rules are not modified nor sidestepped. Modified only is the schedule (ie “pace”, “timeline”) at which clients choose to implement these established procedures. The heaviest (most difficult) chain will – still – always, eventually, win. Proposed only is to make clients somewhat stubborn in their opinion and processing of chains; it makes them sluggish and resistant to big changes. It gives them a (temporary) opinion.
Opinions are allowed under GHOST and the rest of Ethereum’s Yellow Paper (and Satoshi’s email chains). Nowhere is it specified that blocks must be imported or included immediately, nor that a miner must mine on the heaviest chain available to them, nor that submitted transactions must be processed, nor that blocks must be propagated regularly.
The normal functioning of the chain is explained (as in rationalized) by some game theory and economics, but it is not subject to it. Miners are not forced (as in caused by the protocol) to mine on the heaviest chain available to them; they normally do so because they bet that that will turn out to be profitable for them. But sometimes mining on the heaviest chain may not be profitable for them; like if the heaviest chain was apparently made by a criminal, and perpetuating that association may lower the exchange rate of their reward. Miners can mine on whatever chain they want, can include whatever transactions they want, and can process, propagate, postpone, or ignore blocks however they want; all without offending Satoshi or his idolators.
In consideration here is a proposal of CONVENTION for network participants that is designed to keep the network as unified as possible while describing an opinion (implemented as algorithm) that prevents big ugly late-coming chain segments from being immediately and automatically accepted.
This is functionally no different than a thought experiment where the human miners are watching their nodes day-in and day-out, every minute, arbitrating with their own personal opinions about whether or not to allow geth to mine on top of block
10_550_798. Again, they are allowed to do this. They can do this. Sometimes they do do this. This proposal is a specification of a way that they can make this same order of decisions, but with the help of some math, a computer, and heuristics that will allow them to do it in coordination without requiring the use of the world’s most boring conference call.
In fact, one of the first evolutions of this proposal was made by @BelfordZ:
When geth wants to reorganize its existing chain for a too-long or too-old chain segment, have it just send an email to its operator saying: Geth has found a suspicious chain segment and requires a human’s wisdom and advice… and then turn off.
Except for a few fancy bells and whistles (ie maybe not shutting down… :)), and a proposed CONVENTION for determining suspicion, these proposals are more alike than different.
Network participants are allowed to be stubborn curmudgeons with opinions. ECIP1100 wants to help them do that gracefully.
The graphs below show a 200 block chain accepting, sidechaining or rejecting reorganizations of varying relative difficulty and length.
Discussion of Constant Parameters
The polynomial function uses constant parameters
xcap = 2pi/8000 and
amplitude = 15, the values of which are reasoned as follows.
The x cap value of
2pi/8000 causes the peak of the curve (and ultimate ceiling) to occur at 25132 seconds (approximately 7 hours). This falls in between the rates of the previously considered exponential functions. The “ramp up” domain (nearest
x=0) sees a flattened curve, yielding a more generous lenience for competing short segments. The curve eventually intersects the original exponential function at about 900 seconds (15 minutes) at about
The amplitude value of
15 causes the peak to occur at
(2*15)+1 = 31. This value means that the maximum “antigravity” an attack will face is a 31, where the proposed chain would need a total difficulty 31 times that of the chain it would replace.
These values were chosen for ETC with the following assumptions and reasoning.
An bounded exponential function would work in much the same way, although it would not have a continuous ceiling transition and would, in a far-edge case, present an exploitable focal point of vulnerability at that transition.
This feature does not require a hard fork, but the network stands to benefit and avoid risk with majority coordinated acivation.
MinimumSyncPeerspeers. In Core-Geth this value is by default
30 * 13 seconds.
The associated Core-Geth implementation is available here.
The file names describe the test, as well as providing expectations for the outcome of the second chain import via the suffix
<3for the original Ethereum vision