proof of consensus != proof of enforcement also maybe you cant understand it but "L1 should be slow" isn't dogma. it's the cost of letting anyone verify without permission. you can disagree with the tradeoff, but you didn't solve anything. everything works the same its 1+1=2 its the reality of the universe. you love using words like "thermodynamic" so much, its not so hard to understand. its not a bitcoin thing, its any system ever. you started a new kaspa node fresh: - downloads the pruning point proof (just headers, not full blocks) - checks PoW on those headers (only for ordering/consensus, not verifying the txs inside them) - checks ghostdag structure + blue work (only picks the heaviest proof, says nothing about tx validity) - downloads the UTXO set from an untrusted peer (the list of who owns what, streamed to you in chunks) - hashes that set with muhash, compares it to the `utxo_commitment` field in the header (only confirms the set matches a number a miner wrote into the header) - validates txs in the pruning point block only (that single block, against the set it was just handed) - everything before the pruning point: never executed (no scripts run, no signatures checked, data never even downloaded) what verifies what: - PoW: energy was spent on the headers - ghostdag/blue work: this proof is heavier than competing ones - muhash check: the set you received matches a number in the header - nothing: that the number was produced by valid txs following the rules the `utxo_commitment` is just a value in a header. the node confirms "the set i got matches this value." it never confirms "this value came from valid execution." consistency, not correctness. proof of consensus, not proof of enforcement. nodes will rejectrt `utxo_commitment` if: - a utxo set that doesnt hash to the value in the header, meaning someone hands you a snapshot thats been tampered with after the fact. the hashes won't match. rejected - the only thing that breaks the check is a mismatch between the bytes you received and the committed hash. basically checksum. - only way you can reject it meaningfully is you are online at that time, and see the invalid (for you) tx. and out right deny the utxo set. `utxo_commitment` doesnt enforce that the transactions which produced that utxo set were valid. its generated by the miner who mined that block. if devs pushes an update and miners mine based on it during a period. and days pass. you have no idea if it fits your ruleset or not. you just accept it because its the most pow. a fresh node goes: does my downloaded set match this hash? Yes. Accepted. it has no way to know the set contains coins that should never have existed. the `utxo_commitment` proves the set matches what was committed. it does not prove what was committed was legitimate by your rules. it catches tampering with the snapshot, not "fraud" or period of rule change baked into the history, deep enough. its trusting the work, not verification. and assuming the bandwidth a kaspa node spends, you cant have a lot of nodes that you cant easily find one that is telling you to double check that older block. if you can find a copy of the said block of course. assuming only few big cloud runners will be running a full node soon. source:

GitHub

GitHub - kaspanet/rusty-kaspa: Kaspa full-node reference implementation and related libraries in the Rust programming language

Kaspa full-node reference implementation and related libraries in the Rust programming language - kaspanet/rusty-kaspa