besu icon indicating copy to clipboard operation
besu copied to clipboard

QBFT migration: protocol context needs the context for block being proposed

Open jframe opened this issue 3 years ago • 0 comments

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

jframe avatar Dec 09 '21 02:12 jframe