Why do general-execution L2s on Kaspa need ZK-proofs for state commitments?

General-execution L2 networks — those running arbitrary smart-contract logic on an account-based model — cannot easily produce a cryptographic commitment to their full state that Kaspa's L1 can check on-chain. Unlike Kaspa's own UTXO model, which has a well-defined commitment format already baked into the block header, summarizing the entire state of a general account-model system in a way a simple on-chain rule can verify is a non-trivial problem that requires ZK-proofs. Kaspa has plans for supporting such commitments posted to the DAG and verified by L1 opcodes, but the specifics are still under discussion with no clear timeline. For beginners, this means that while simpler L2 applications can build on Kaspa today, full general smart-contract L2s face an open research challenge around proving their state is valid to the underlying chain.