菜单
Foundational impossibility result proving consensus cannot be guaranteed in asynchronous systems with even one faulty process
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/curiositech/windags-skills --skill fischer-lynch-paterson-1985-flp-impossibility命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
基于 SOC 职业分类
| license | Apache-2.0 |
| name | fischer-lynch-paterson-1985-flp-impossibility |
| description | Foundational impossibility result proving consensus cannot be guaranteed in asynchronous systems with even one faulty process |
| category | Research & Academic |
| tags | ["distributed-systems","consensus","impossibility","fault-tolerance","theory"] |
Given system constraints → Choose approach:
IF no timing assumptions allowed AND exact consensus required
├── THEN consensus is impossible
├── → Redesign to avoid coordination
└── → OR accept potential non-termination + add manual escape
IF timing assumptions acceptable (timeouts, heartbeats allowed)
├── AND need strong consistency
├── → Use Paxos/Raft family protocols
└── → Monitor timing assumption violations
IF approximate results acceptable
├── OR partial agreement sufficient
├── → Use best-effort protocols
└── → Trade precision for availability
IF static participant set AND known failure bound
├── → Use majority protocol
└── → (Consensus IS possible in this case)
System stuck without deciding → Check cause:
IF cannot distinguish slow from crashed processes
├── → You've hit FLP boundary
├── → Add failure detector (timeout) OR accept non-termination
└── → Document synchrony assumptions if using timeouts
IF system has timing assumptions but still hangs
├── → Assumptions violated (network partition, load spike)
├── → Check: timeout too aggressive? GC pause? Network delay?
└── → Adjust assumptions OR add assumption violation handling
IF in bivalent state (can decide either way)
├── → Normal FLP scenario - not a bug
├── → Add escape hatch: manual override, quorum adjustment
└── → OR wait for network/timing conditions to improve
Setting failure detection timeout → Balance false positives vs negatives:
IF timeout too short
├── → False positives: declare live process dead
├── → Leads to: split decisions, unnecessary failovers
└── → SOLUTION: make adaptive, increase under load
IF timeout too long
├── → False negatives: don't detect real failures
├── → Leads to: long waits, poor user experience
└── → SOLUTION: expose partial results, manual override
ALWAYS:
├── → Log timeout violations to validate assumptions
├── → Design protocol to handle false positives gracefully
└── → Make timing assumptions explicit in documentation
Aggregating parallel task results → Check operation properties:
IF aggregation is commutative/associative (order doesn't matter)
├── → Process results as they arrive
├── → Minimal coordination needed
└── → Example: sum, max, set union
IF aggregation requires specific order OR all inputs
├── → Requires coordination protocol
├── → Apply coordination strategy selection (Decision Point 1)
└── → Example: consensus on final decision, ordered operations
IF some tasks might not complete
├── → Wait forever (pure asynchrony) OR timeout (synchrony assumption)
├── → Recommend: expose both modes
└── → Strict mode vs best-effort mode
Symptom: System still hangs despite hardware upgrades, faster networks, optimized code Diagnosis: Treating impossibility as performance problem Detection Rule: If you're saying "we'll make it fast enough that failures don't matter" Fix: Accept the trade-off, choose which guarantee to sacrifice (usually pure asynchrony via timeouts)
Symptom: System works in testing but fails unpredictably in production during network issues Diagnosis: Using timeouts/heartbeats without acknowledging synchrony assumptions Detection Rule: If your "asynchronous" system has any timeout values Fix: Document timing assumptions explicitly, monitor violations, design for assumption breaches
Symptom: System appears frozen, users can't proceed, no error message or recovery option Diagnosis: Protocol blocks indefinitely waiting for consensus without escape hatch Detection Rule: If system can enter a state where it waits forever with no user recourse Fix: Add timeouts, manual override, quorum adjustment, or "decide with available data" mode
Symptom: Operators can't tell if system is making progress or stuck, debugging is impossible Diagnosis: Treating consensus as black box without exposing internal state Detection Rule: If you can't answer "is the system stuck or still working?" Fix: Expose bivalent/univalent state, show which processes voted, add progress indicators
Symptom: Applying FLP reasoning to problems that don't need binary consensus Diagnosis: Over-applying impossibility result to leader election, ordering, or best-effort coordination Detection Rule: If you're using "FLP says it's impossible" for non-consensus problems Fix: Distinguish exact consensus from other coordination patterns, use appropriate guarantees
Scenario: 5 AI agents must reach consensus on whether to approve a pull request. Each agent analyzes different aspects (security, performance, style, tests, logic).
Expert Decision Process:
What novice misses:
Expert solution:
Scenario: 100 agents processing data chunks, need to aggregate results into final report. Some agents might fail.
Expert Decision Process:
FLP implications:
Expert solution:
Scenario: Raft-based coordination system appears stuck during leader election.
Expert Diagnosis Process:
What novice sees: "Consensus is broken, FLP proves this is impossible" What expert sees: "Synchrony assumptions violated, this is expected behavior"
Expert solution:
Task completion checklist for applying FLP knowledge:
Do NOT use this skill for:
Delegate to other skills when: