nomadshiba⚡⚡'s avatar
nomadshiba⚡⚡ me@nomadshiba.me 1 month ago
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
↑ Parent

Replies (1)

WildBill's avatar
WildBill 1 month ago
You just laid out the sync process perfectly, but you missed the foundational rule of cryptography: A miner cannot dictate the hash; the math dictates the hash. You claim the node just confirms the UTXO set matches the number the miner wrote into the header, without knowing if the transactions were valid. But a miner cannot just write any random number they want. The ⁠utxo_commitment⁠ is a strict mathematical result of the ledger's entire history. If a miner tried to bake fake coins into that history a year ago, every honest node online at that exact second would have rejected the block instantly. That invalid block would have been orphaned and left in the dust. The only way that 'fake coin' hash could become the heaviest, valid Pruning Point Proof handed to a fresh node today is if the rogue miners successfully sustained a 51% attack against the honest network for an entire year. Kaspa didn't abandon verification. Kaspa realized that if an honest majority enforces the rules in real-time, the resulting Proof-of-Work header chain becomes an unforgeable cryptographic proof of the valid ledger state. You don't need to turn your hard drive into a museum of ancient data to enforce the rules of the present. It’s sad to me you don’t understand this.
1 replies ↓
↑