Identifier: Core-SV-005
Many of the public testers might have thought that double forging was mitigated and solved during the testing phase, but this was never the case. Double forging appeared to be working more correctly due to the way we handled transaction propagation in the initial versions of Core v2. All nodes had homogeneous transaction pools and were broadcasting to all peers. The double forged blocks had the same content and same IDs. That is why it was not detected as an issue during initial public testing.
That being said, at any given time a malicious forger could and still can forge multiple distinct blocks and broadcast them to different peers causing instability in the network.
There is an AIP-24: Double Forging Improvements draft in progress that will address this issue, but requires careful consideration.
Until then, forging delegates need to make sure they do NOT run two or more servers with the forger process ‘on’ and passphrase set, have more relay nodes in front of their forging delegate, and that they don’t run automatic scripts to switch the forgers. We have seen failover scripts cause double forging that halts the network in the past and until a solution is in place, this practice risks harming the network.
Reported by: alessio
The network as of now detects double forging and tries to recover via fork management, but this isn’t optimal and still leaves room for user or script errors.
Patch: TBD Work In Progress: https://github.com/ArkEcosystem/AIPs/blob/master/AIPS/aip-24.md
Open.
Release: TBD