Why an Acknowledgment Cannot End the Doubt
Imagine two computers trying to coordinate a change. The first sends “switch at noon,” and the second replies “confirmed.” If that reply arrives, the first computer knows the second received the message. But the second cannot know the first received its confirmation. It might send another acknowledgment—yet then the same uncertainty applies to that new message.
This is not merely a problem of slow communication. If messages can disappear without warning, silence gives no clue about what happened. The sender cannot distinguish a lost message from a lost reply, and no finite sequence of messages can establish that both sides know the other knows they agree. In logic, that shared certainty is called common knowledge.
Real Systems Settle for Practical Guarantees
The result does not mean computers can never coordinate. It means an unconditional guarantee is impossible under the assumption that messages may be lost indefinitely. Working systems therefore rely on additional conditions: for example, that messages will eventually get through, or that a group can make decisions when enough members respond. Timeouts can trigger retries or recovery, but a timeout alone cannot prove that a silent computer has failed; it may simply be delayed.
Consensus protocols are designed around such assumptions and goals. They can provide strong guarantees when their stated conditions hold, while accepting that communication failures may delay a decision or leave some participants uncertain. The key engineering choice is not how to send one last, perfect confirmation. It is what the system should do when certainty cannot be obtained—especially whether to wait, retry, or proceed with a decision supported by the available participants.
