Replace service date by numbered forks #2272
Conversation
| validateForkNumber :: Parent BlockHeader -> BlockHeader -> Bool | ||
| validateForkNumber (Parent parent) hdr | ||
| | isForkEpoch hdr = | ||
| if view getForkNumberVotes parent >= (forkEpochLength * 2 `div 3) |
There was a problem hiding this comment.
syntax error, missing back tick
and is this 3 supposed to be graph diameter? if so we need to get the graph diameter from the blockheader, not hardcode
There was a problem hiding this comment.
I think the idea here is to allow fork votes to pass given that 2/3 of the blocks vote in favor.
There was a problem hiding this comment.
yes, the PR proposes that a super-majority is required.
The idea is that a forking changes only triggers when there is already sufficient support for it such the two branches of the network growth at different rates. The forking branch would establish itself is the clear winner, preventing inefficiencies and potential load spikes due to intermittent reorgs.
It probably also is generally a good idea to be conservative. In the "code is law" paradigm of a decentralized blockchain, a forking protocol change is a kind of constitutional change.
3 participants
[This is work in progress.]
The goal is to replace the current service dates by forks that are voted for by miners, usually by installing the next version of the software. But it would also possible to vote via, say, a command line flag or some other configuration option.
It guarantees continuous operation of the network without the need of regular service releases. It also allows to react in a more agile way to issues and rollout changes on an on-demand basis.
Service date releases are well suited for incremental software improvements that are non-controversial among the the users of the system. Updates that affect economic incentives of the system should be affirmed explicitly by the block producers. This PR introduces such a mechanism.