phoenix protocol

[SurfingNerd]

interval (~ heartbeat * 1,2) based retrying of block creation.

• 1,2: deleting local state
• 1,5: starting of new block

[dforsten]

Introduction

Recovering from stalls caused by hbbft consensus failures.

• Even in slow networks a hbbft consensus round should not take longer than 5 minutes (usually it takes a couple of seconds).
• If a hbbft consensus round takes longer than 5 minutes it will likely not recover on its own.
  • Exception: longer lasting network partitions
• Fixing all corner cases which may lead to such a condition will likely take years of testing and development.
  • Low frequency corner cases.
• Need a catch-all recovery mechanism (a.k.a. "Phoenix Protocol")

We do require somewhat synchronous clocks between validators, not synchronized clocks de-facto define a validator as invalid.

Max. assumed time deviation tolerance between node clocks: 1 minute

Overview

Phoenix Protocol Phases

• Wait 5 Minutes past last scheduled heartbeat.
  • Block creation considered stalled
  • Count from timestamp of last block to synchronize time offset
• Buffer for network latency/local clock deviations
  • Lasts 1 minute
  • Do not send any consensus messages, but receive messages
  • Due to latency/clock deviations messages from the past or even the future might be received!
• Moratorium phase II
  • Lasts 1 minute
  • Reset internal hbbft state for the current block
  • Do not send any consensus message
  • Allow receiving of consensus messages
• Moratorium phase III
  • Start sending consensus messages

This sums up to a total of 7 minutes

Next kick-ins of Phoenix Protocol:

• 2nd moratorium start: 12 minutes
• 2nd moratorium end: 14 minutes
• 3rd moratorium start: 19 minutes
• 3rd moratorium end: 21 minutes

[cryptonit]

to avoid issues with messages from older attempts
i think we should consider have a blocknumber+attempt
and not only blocknumber in the messages

so when they start with block xy attempt 2 never a by what reason ever delayed message can be mixed in