ZK-STARK와 PLONK 증명 시스템 비교: 증명 크기·검증 비용·사후 양자 안전성 기준 선택 가이드
PLONK is the better choice when smaller proofs and lower verification gas are the primary constraints, while STARK is the better choice when trusted-setup risk and post-quantum security matter more.
Comparison Overview
ZK-STARK and PLONK both deliver zero-knowledge proofs, but they optimize for different priorities in production systems. STARK relies on hash-based commitments and FFT-heavy verification logic, while PLONK uses a universal polynomial commitment model with a reusable setup ceremony. In practice, the selection hinges on whether a team values lower calldata and lower verification gas more than transparent setup and stronger long-horizon post-quantum assurances.
ZK-STARK Analysis
A typical STARK proof for a 100k-gate circuit is about 45 KB, which materially increases calldata footprint versus PLONK. Verification on Ethereum is about 600k gas, so STARK can be roughly twice as expensive to verify as PLONK for comparable security levels. The upside is that STARK removes trusted setup entirely and bases soundness on hash collision resistance, making it the stronger fit for systems that prioritize setup transparency and post-quantum resilience.
PLONK Analysis
PLONK compresses an equivalent proof to about 15 KB, making it roughly 67% smaller than STARK in the cited comparison. Verification averages around 300k gas on Ethereum, which substantially improves unit economics for rollups and other proof-heavy applications. Its main compromise is the trusted setup ceremony, because toxic-waste leakage would undermine future proofs even though the universal setup is reusable across many circuits.
Trade-offs and Conclusion
If proof size and verification cost dominate the decision, PLONK is the more operationally efficient choice because it cuts proof size by two-thirds and halves verification gas relative to STARK. If the trust model and long-term cryptographic durability matter more, STARK is preferable because it avoids trusted setup and retains post-quantum security rooted in hash assumptions. The real decision is therefore not which system is universally better, but which risk profile and cost structure best matches the target deployment.