Impossibility Under Asynchrony: What Consensus Cannot Promise
With no bound on message delay and one process allowed to fail, no algorithm is guaranteed both to agree and to finish. Real systems live with this by giving up guaranteed termination and leaning on timeouts, which are a failure detector under another name.
What a learner can do afterwards
- State the two properties the impossibility result puts in conflict and the model it assumes
- Say which property practical systems relax, and what a timeout is standing in for
- Explain why a slow process and a failed process cannot be told apart in this model
1 · Read
With no bound on message delay and one process allowed to crash, no algorithm guarantees both agreement and finishing. That clash is the impossibility result, and its model assumes crash failures with fully asynchronous messages.
A process goes silent. It may have crashed, or its messages may just be slow, and nothing in the model tells the two apart. Waiting forever risks never finishing, while deciding without it risks agreeing wrongly.
Practical systems relax guaranteed finishing and lean on timeouts instead. A timeout says no news after some wait counts as failed, which makes it a failure detector under another name. It can wrongly suspect a merely slow process.
State the price precisely: asynchrony plus one crash means agreement and guaranteed finish cannot both hold. Then say which guarantee your system gives up.
Async plus one crash forbids promising both agreement and finish, so systems trade finish for timeouts.
2 · Watch
Take it off screen
Where it sits
8 questions wait behind this lesson, each with its answer explained. Every answer feeds the sky: stars light as they are learned, and dim when it is time to come back.