besu
besu copied to clipboard
QBFT migration: protocol context needs the context for block being proposed
When attempting to migrate from IBFT2 to QBFT the migration fails on a class cast exception due to the protocol context for IBFT being used when creating the proposed block for QBFT.
Acceptance Criteria
- QBFT protocol context is returned when QBFT is creating the proposed block
- When syncing an existing chain validation rules use the appropriate protocol context for the migration schedule.
- Manual and unit tests. There is not infrastructure to do integration tests for a IBFT to QBFT migration currently
Idea Could change the MigratingProtocolContext to add a getProtocolContextForNextBlock
public <C extends ConsensusContext> C getProtocolContextForNextBlock(final Class<C> klass) {
final long chainHeadBlockNumber = getBlockchain().getChainHeadBlockNumber();
return consensusContextSchedule.getFork(chainHeadBlockNumber + 1).getValue().as(klass);
}
Note:
- The QbftBlockCreatorFactory create requires the protocol context for the block it going to create. Normally this is the same. But when migrating from IBFT to QBFT the next proposed block could be a QBFT block and we need the protocol context for QBFT otherwise will create a IBFT block.
- ProposalPayloadValidator also needs to get the correct context.
- If start the node at or after the migration block then you'll get an RLP exception at startup instead because it's trying to use the QbftExtraDataCodec to decode an IBFT block header. Not sure if the fix above will work for this, it might require a slightly different or additional solution. See https://github.com/hyperledger/besu/issues/3469