I wonder why only the ForkDigest is rolled on a BPO, without the ForkVersion.
The problem with only rolling the ForkDigest is that after the BPO activates, network traffic from clients that did not upgrade remains valid on the network partition of clients that upgraded. This essentially provides withholding-as-a-service, which was a big topic back when fork choice security was revisited.
- Imagine 1/3rd didn’t update, and gets the first 17 blocks around the BPO activation (probability comparable to winning powerball lottery, which periodically happens in practice).
- Then, 1 malicious node re-broadcasts the head of these blocks on the new network partition, or maybe even just attestations to these blocks
- Peers on the new network partition have not seen any parents, and will req/rsp the missing data. Only the malicious node initially has the data, leading their nodes to gain peer score while the honest but useless peers without the data may lose peer score
Questions are:
- Is BPO safe from a perspective of fork choice?
- Is BPO safe from a perspective of sync performance?
- Why not also roll ForkVersion?
Full hard forks require extensive coordination, testing, and implementation changes beyond parameter adjustments. For example, in Lighthouse, a typical hard fork implementation requires thousands of lines of boilerplate before any protocol changes occur. BPO forks streamline this process by avoiding the need for this boilerplate code.
The EIP rationale doesn’t make sense to me. The same coordination is required for a BPO: All users have to update clients before it activates, and the node consumes more resources after the fork, possibly requiring hardware upgrades; the experience for users is exactly the same as for a full blown fork.
Fork version could be similarly designed as a “parameter adjustment”. One has to be careful though to choose globally (across all chains) unique (fork_version, genesis_validators_root) tuples to avoid slashings across chains.