Fraud Proofs vs. Validity Proofs: The Game Theory TODO
Concept
Fraud-proof systems provisionally assume a submitted state transition is valid, and roll it back via on-chain verification only if someone flags a fault within the challenge window. This scheme's safety rests not on cryptography but on game-theoretic assumptions: at least one honest challenger must exist (1-of-N), and that challenger must be able to get a transaction onto L1 within the challenge window without being censored. This creates the verifier's dilemma — verification always costs something, but the payoff only materializes if fraud actually occurred, so a rational participant has an incentive to skip verification; bonds and slashing are used to correct for that. Validity-proof systems instead show cryptographically that the state transition followed the rules, so they need neither an honest-watcher assumption nor a challenge window. In exchange, the risk shifts to the cost of generating proofs and to the trusted setup or implementation bugs of the proof system itself. So the real difference between the two isn't 'who do you trust' — it's whether the risk lives in incentive design or in cryptography and code.
Once assets live on an L2, the withdrawal delay, the assumption that a challenger exists, and censorship resistance become the actual safety conditions on user funds. Miss this and you'll misjudge the real trust assumptions in a bridge or settlement design.
Code & Formula
# 사기 증명 vs 유효성 증명의 게임 이론 — 본드·이득·검증비용·적발확률로 "사기가 손해"인 조건을 구한다.
# 기대이익 = (1-p)*이득 - p*본드 가 0보다 작아야 사기가 억제되며, 그 경계 p*를 계산한다.
def expected_profit_from_fraud(gain, bond, detect_prob):
return (1 - detect_prob) * gain - detect_prob * bond
gain = 50_000 # 사기가 성공했을 때 얻는 이득
bond = 100_000 # 사기가 적발되면 몰수당하는 본드(슬래싱)
challenge_cost = 500 # 정직한 챌린저가 검증·이의제기에 쓰는 비용
for detect_prob in (0.3, 0.5, 0.7, 0.9):
ev = expected_profit_from_fraud(gain, bond, detect_prob)
verdict = "사기 시도가 이득" if ev > 0 else "사기 시도가 손해(억제됨)"
print(f"적발확률 p={detect_prob:.1f} → 기대이익={ev:,.0f} → {verdict}")
# 손익분기 적발확률: (1-p)*gain - p*bond = 0 => p* = gain / (gain + bond)
breakeven_p = gain / (gain + bond)
print(f"\n손익분기 적발확률 p* = {breakeven_p:.3f} (이보다 낮으면 사기가 합리적 선택이 된다)")
# verifier's dilemma: 챌린지 비용이 있으므로, 적발 시 보상이 최소 challenge_cost는 넘어야
# 합리적 챌린저가 실제로 나선다 — 그렇지 않으면 아무도 검증하지 않아 p 자체가 0에 가까워진다
slashed_reward_share = bond * 0.1 # 슬래싱된 본드의 10%를 챌린저에게 분배한다고 가정
incentive = "있음" if slashed_reward_share > challenge_cost else "없음"
print(f"챌린저 보상(본드의 10%)={slashed_reward_share:,.0f} vs 챌린지 비용={challenge_cost:,} → 챌린저가 나설 유인 {incentive}")
docs/code/algorithms/algorithms-65.py
Exercise
Set bond size, the payoff from a successful fraud attempt, challenge cost, and detection probability as variables, write out the inequality that makes attempting fraud unprofitable, and work out which parameter breaking makes the attack profitable.
Practical Connection
If Verex settles on an L2 or rollup, the challenge period sets the floor on when a winner can actually withdraw funds, so the UX design from market close to fund withdrawal is directly tied to this choice.
Where it lands in Jayverse
- Verex: decide who plays the honest challenger. If settlement runs through an optimistic path, the verifier's dilemma means someone must be economically incentivized to watch and challenge — assign that role and bond it rather than assuming it happens.
- Devnet: put real numbers into the fraud-attempt inequality. Before fixing a rollup choice, compute bond size, fraud payoff, challenge cost and detection probability for Verex's actual settlement design, not as an abstract exercise.
- Bridge: check censorship resistance for any optimistic-rollup path. If the bridge ever settles through one, record whether a challenge transaction can always land on L1 within the window, the same assumption the challenge-window design depends on.
Key expressions
| Expression | 뜻 · 쓰이는 자리 |
|---|---|
| provisionally | 잠정적으로, 일단은 · "provisionally assume a submitted state transition is valid" |
| roll back | (상태를) 되돌리다 · "roll it back via on-chain verification" |
| verifier's dilemma | 검증자의 딜레마(검증 비용은 드는데 보상은 불확실한 상황) · "This creates the verifier's dilemma" |
| rational | 이기적으로 계산해서 합리적으로 행동하는 · "a rational participant has an incentive to skip verification" |
| slashing | 예치금을 몰수/삭감하는 벌칙 · "bonds and slashing are used to correct for that" |
| shift (risk) | 위험이 다른 쪽으로 옮겨가다 · "the risk shifts to the cost of generating proofs" |
| set the floor on | ~의 하한선을 정하다 · "sets the floor on when a winner can actually withdraw" |
| trusted setup | 신뢰된 설정(trusted setup) · zk-SNARK 등에서 초기 매개변수를 생성하는 절차, 손상되면 증명 시스템 전체가 위험해짐. "the trusted setup or implementation bugs of the proof system itself" |
If you study this on a given day, add a note link and a ✅ to this line in the source curriculum (docs/knowledge/dev-100-curriculum.md) and this spot will lead straight to the note body. You can also write directly on this page — but regenerating overwrites it, so it's safer to keep anything you want to save as markdown under docs/algorithms/.