The familiar 3f+1 construction is tied to a model, not a universal law for every authenticated synchronous or randomized agreement problem. Stronger timing assumptions, trusted components, or different protocols change what can be achieved. Signatures also need key management and a defined membership. Counting a thousand identities controlled by one adversary as a thousand independent honest machines is a Sybil problem, not fault tolerance.
Agreement among replicas does not prove that the input reflects reality. All honest replicas can consistently process a false sensor report, a fraudulent but authorized request, or buggy application code. Byzantine fault tolerance protects the defined agreement boundary. It does not replace access control, input validation, cryptographic key protection, or independent failure domains. A complete specialist treatment of Byzantine protocols and cryptocurrency consensus is beyond this course; the goal here is to understand their assumptions and claims.
Keep trustworthy agreement separate from trustworthy inputs
Byzantine agreement has an explicit boundary around the replicated service. Suppose honest replicas deterministically process an authenticated instruction to change a delivery address. If the customer's key was stolen, the replicas can agree perfectly on an unauthorized action in the customer's real-world sense. The protocol has not learned who physically held the key. Application authorization must decide which keys may request which transitions, and revocation must define when a key stops having that permission. Agreement then orders those decisions under the chosen contract.
Likewise, replicating a computation does not diversify identical application code. A deterministic bug can make every honest replica calculate the same incorrect invoice. Relative to the replication protocol, those replicas may have followed every prescribed step. Relative to the business specification, the result is wrong. A claim that a system tolerates one Byzantine replica does not establish that it tolerates every common compiler error, compromised software update, or mistaken administrator command. Those events may corrupt more members than the stated bound, or occur outside the agreement boundary entirely.
Recovery also affects the boundary. An honest member that restarts must recover the protocol obligations required by its implementation before voting again. Restoring an old disk image while retaining the same voting identity can make it forget restrictions that other members still rely on. Alternatively, replacing that identity requires a safe configuration transition. A signature key identifies the signer across these events, but does not restore its missing history. The exact persistent records depend on the protocol; this lesson does not prescribe a generic Byzantine recovery file format.
Client observation requires its own rule. A reply from one authenticated replica proves that replica sent the reply, not that the reply reports an agreed and applied result. A Byzantine service must specify the authenticated evidence or matching responses a client needs, and how those responses relate to the committed operation. Read protocols must also prevent a stale state from masquerading as a current result. The earlier lesson's distinction between current authority and an applied prefix remains useful, although Byzantine protocols require their own proof rather than copying Raft's read procedure.
Finally, separate delay from deception when diagnosing progress. A replica that has not answered might be faulty, partitioned, or slow. Honest members cannot infer which explanation holds from silence alone. Authenticated synchronous agreement results use timing assumptions that differ from partially synchronous services, and randomized protocols have different termination statements. The earlier FLP lesson rules out unconditional deterministic termination in its asynchronous crash model; signatures do not simply remove that uncertainty. When reading a Byzantine-system claim, identify the member identities, maximum faulty population, timing assumptions, decision evidence, and protected object. Those details determine whether an honest-intersection calculation is relevant and which failures remain outside the promised guarantee.