Liveness verification System liveness is continuously validated by comparing the latest block height reported by peers with the height observed by the watchtower. If the difference falls outside the acceptable tolerance range, the protocol treats the state as unreliable. During the active ping-pong phase, the step is rejected and does not advance progress. If detected before ping-pong begins, the protocol safely falls back and initiates fault attribution to preserve consistency and trust.
Hardware redundancy All critical hardware components are provisioned with a verified backup during the setup ceremony. This backup is designed to securely replace the primary device if needed, ensuring operational continuity without weakening the protocol’s security guarantees.
Both mechanisms are already accounted for in the roadmap and will be fully specified during the ancillary design and implementation phase, where detailed engineering and operational procedures are finalized. We are not there yet.
Thanks @bodhi for the question.
System liveness is continuously validated by comparing the latest block height reported by peers with the height observed by the watchtower. If the difference falls outside the acceptable tolerance range, the protocol treats the state as unreliable. During the active ping-pong phase, the step is rejected and does not advance progress. If detected before ping-pong begins, the protocol safely falls back and initiates fault attribution to preserve consistency and trust.
All critical hardware components are provisioned with a verified backup during the setup ceremony. This backup is designed to securely replace the primary device if needed, ensuring operational continuity without weakening the protocol’s security guarantees.
Both mechanisms are already accounted for in the roadmap and will be fully specified during the ancillary design and implementation phase, where detailed engineering and operational procedures are finalized. We are not there yet.