[Review] A design checklist for verifiable systems TODO
Concept
A verifiable system is designed so the other party can confirm the correctness of a result for themselves, instead of being asked to just trust it. The core axes are determinism (same input, same output), commitments (pinning state via a Merkle root or hash), the proof method (validity proof, Merkle proof, or fraud proof), and the trust assumptions plus data availability. Verifiability only has real meaning when verification cost is reliably lower than the cost of re-execution. Finally, the design isn't complete until the recovery path on failure is spelled out too — the challenge period, the escalation procedure, and who holds ultimate fallback authority.
Bolting on a proof system doesn't make you safe by itself; unless the trust assumptions and fallback path are pinned down in writing, nobody knows who can do what at the moment an incident actually happens.
Code & Formula
# [복습] 검증 가능한 시스템 체크리스트 — 결정성·커밋먼트·증명 방식·검증 비용을
# 머클 트리로 시연: 잎 하나의 값을 O(log n) 증명으로 검증(전체 재실행 O(n) 불필요).
import hashlib
def H(*parts) -> bytes:
m = hashlib.sha256()
for p in parts:
m.update(p)
return m.digest()
def build_tree(leaves):
level = [H(b"leaf", x) for x in leaves]
tree = [level]
while len(level) > 1:
if len(level) % 2:
level = level + [level[-1]]
level = [H(b"node", level[i], level[i + 1]) for i in range(0, len(level), 2)]
tree.append(level)
return tree # tree[0]=leaf hashes ... tree[-1]=[root]
def merkle_proof(tree, index):
proof = []
for level in tree[:-1]:
sibling = index ^ 1
if sibling < len(level):
proof.append(level[sibling])
index //= 2
return proof
def verify_proof(leaf, index, proof, root):
h = H(b"leaf", leaf)
for sib in proof:
h = H(b"node", sib, h) if index % 2 else H(b"node", h, sib)
index //= 2
return h == root
leaves = [f"account-{i}:balance={i*10}".encode() for i in range(8)]
tree = build_tree(leaves)
root = tree[-1][0]
idx = 5
proof = merkle_proof(tree, idx)
print("커밋먼트(root):", root.hex()[:16], "...")
print(f"leaf[{idx}] 증명 크기: {len(proof)} 해시 (전체 잎 {len(leaves)}개 재실행 없이 검증)")
print("증명 검증 결과:", verify_proof(leaves[idx], idx, proof, root))
tampered_leaf = b"account-5:balance=9999"
print("변조된 leaf 는 같은 증명으로 거부됨:", not verify_proof(tampered_leaf, idx, proof, root))
# 체크리스트: 결정성(같은 입력->같은 root) / 커밋먼트(root) / 증명방식(머클 증명)
# / 검증 비용(O(log n) < 재실행 O(n)) / 폴백(불일치 시 이의제기 대상은 root 제공자)
print("\n[체크리스트] 결정성 O, 커밋먼트 O, 증명방식=머클, 검증<재실행 O, 폴백 주체=? (명시 필요)")
docs/code/algorithms/algorithms-96.py
Exercise
Pick one system you've built and fill in a one-page table covering trust assumptions, commitments, who verifies, the challenge period, and the final fallback — then find which cells are left blank.
Practical Connection
Verex's result-finalization path (oracle proposal → challenge period → final settlement) is a direct application of this checklist, and the trust assumptions and fallback authority at each step need to be written down explicitly to be able to respond during a dispute.
Where it lands in Jayverse
- Auditor: fill in the one-page table (trust assumptions, commitments, who verifies, challenge period, final fallback) for Verex's finalization path as an actual written doc before the first dispute, not after.
- Bridge: name the Anvil-Sepolia relayer's proof method explicitly as a gap. It currently runs on trust-the-relayer with no fraud or validity proof; decide the challenge-period and fallback-authority design before real capital crosses it.
- Number: if a reading is ever distributed with a commitment (a hash pinning a dataset version), state who can verify it without re-running the analysis. Verifiability only counts once verify-cost is confirmed lower than re-execution cost.
Key expressions
| Expression | 뜻 · 쓰이는 자리 |
|---|---|
| bolt on | (검증 없이) 덧붙이다·갖다 붙이다 · 근본 설계 없이 증명 시스템만 얹는 것을 비판할 때. "Bolting on a proof system doesn't make you safe" |
| pin down | 명확히 못박다·구체적으로 정해두다 · 신뢰 가정을 문서로 확실히 규정해야 할 때. "pinned down in writing" |
| fallback authority | 최종 책임자·최후 결정 권한 · 문제가 터졌을 때 최종적으로 판단할 권한을 가진 주체. "who holds ultimate fallback authority" |
| challenge period | 이의제기 기간 · 결과를 확정하기 전에 반박할 수 있게 두는 유예 기간. "the challenge period, the escalation procedure" |
| escalation procedure | 상황 에스컬레이션 절차 · 문제가 커질 때 단계적으로 위로 보고·처리하는 절차. "the challenge period, the escalation procedure" |
| data availability | 데이터 가용성 · 검증에 필요한 데이터를 누구나 실제로 확인할 수 있는지 여부. "the trust assumptions plus data availability" |
| at the moment | 바로 그 순간에·막상 닥쳤을 때 · 사고가 실제로 터지는 시점을 강조할 때. "at the moment an incident actually happens" |
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/.