Trusted Setup vs. Transparency (STARK vs. SNARK) TODO
Concept
Many SNARKs require a trusted setup to generate public parameters before the proof system can be used, and if the secret value used in that process (often called "toxic waste") is not destroyed, forged proofs become possible. That's why an MPC ceremony is used to make the setup secure as long as just one participant is honest, and universal, updatable setups like KZG-based ones — which don't need to be redone per circuit — are preferred. STARKs rely only on hash functions and error-correcting codes, so they have no secret parameters at all, making them transparent and eliminating the setup trust assumption. The cost is proof size and verification cost: STARK proofs are generally larger than pairing-based SNARK proofs. Being hash-based is also often cited as giving STARKs a more conservative security assumption against quantum attacks.
Choosing a proof system is a question of trust assumptions before it's a question of performance — if the setup is compromised, everything verified on top of it becomes meaningless.
Code & Formula
# 신뢰된 셋업 vs 투명성(STARK vs SNARK) — 신뢰된 셋업이 있는 스킴은 "독성 폐기물"(toxic
# waste, 셋업에 쓰인 비밀 난수)이 새면 위조 증명이 가능해진다는 걸 토이 버전으로 보여준다.
import random
def trusted_setup():
# 이 비밀(tau)을 아무도 몰라야 안전 — 만약 한 명이라도 저장해 두면 "독성 폐기물" 유출.
tau = random.randint(1, 10**9)
public_params = pow(2, tau, 10**9 + 7) # 공개되는 건 tau 로 만든 파생값뿐
return tau, public_params
def verify_honest_proof(public_params, claimed_value):
return claimed_value == public_params
def forge_with_leaked_tau(tau):
# tau 가 새어 나가면 검증자를 속이는 "증명"을 그냥 다시 계산해서 만들 수 있다.
return pow(2, tau, 10**9 + 7)
tau, params = trusted_setup()
print(f"신뢰된 셋업 공개 파라미터 = {params}")
print("정직한 증명자:", verify_honest_proof(params, params), "(정상 검증 통과)")
forged = forge_with_leaked_tau(tau) # tau 를 안다면 누구나 위조 가능
print("tau 유출 시 위조 증명도 검증 통과:", verify_honest_proof(params, forged))
print("\n반대로 STARK 류(투명성)는 이런 비밀 tau 자체가 없다 — 공개 무작위성(예: 해시)만")
print("쓰므로 '독성 폐기물'이 존재하지 않는다. 대가는 증명 크기가 더 크다는 것.")
Exercise
Prove the same simple circuit using both a library that needs a trusted setup and one that's transparent, then tabulate the presence/absence of setup artifacts, proof size, and verification time.
Practical Connection
When reviewing a validity proof for an L2 rollup, or privacy and off-chain computation verification for a prediction market, on-chain verification gas and setup trust assumptions are decided exactly on this trade-off.
If you study this on a given day, add a note link and a ✅ to this line in the source curriculum (docs/knowledge/math-50-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/.