LTBD

bitcoin

Citrea's [blog post][1] describes the lifecycle of their transactions:

>[...]the technical process begins with users sending transactions to a full node. Upon receiving these transactions, the full node sends them to a sequencer for soft confirmations. Anyone who wants to access Citrea's transaction history or wants to query data can set up a Citrea full node.
A sequencer is a type of full node that soft-confirms the transactions and builds blocks. It then propagates these soft confirmations, soft blocks, to every full node available. The purpose of soft-confirmations is to provide users with fast transaction experience. The next step involves a special type of full node that is used for zero-knowledge rollups. This full node is called Prover and has an important role in inheriting Bitcoin security for user's transactions.
>
>A prover, as all full-nodes do, receives the soft confirmations from the sequencer and keeps the data. What makes a prover special is that it creates a batch by roll-ing up the transactions that the sequencer has soft confirmed.
>
>Then, it generates a zero knowledge proof of this batch for anyone to verify 
its validity. The prover does not only generate the proof but also creates a data called state 
difference - which is the storage slots difference between the initial and latest state. 
**Creating state differences is what makes Citrea’s Bitcoin blockspace usage efficient. Since Bitcoin blockspace is limited and expensive, Citrea inscribes state differences instead of full transactional data to minimize blockspace usage and the data cost.** 
>
>There is one caveat; proof producing is not instant. There is a cost to proving. The more transactions the batch contains, the cheaper each transaction data becomes. Therefore, the prover collects the transactions until the cost of creating the zero-knowledge proof of the batch reaches an optimal cost. To ensure 
that no one can alter the ordering while validity proof is being generated, **the sequencer inscribes the Merkle root of the batch to Bitcoin every 10 minutes.** The prover makes sure that the zero knowledge proof is generated based on the ordering submitted to Bitcoin.

Does proof generation on Citrea start as soon as the sequencer finalizes the batch? Or do they start generating the proof but wait with inscribing the state differences till the corresponding Merkle root gets confirmed with a certain number of blocks? Or rather do they start proof generation after a certain number of blocks confirming the inscription of the batch's Merkle root?


[1]: https://www.blog.citrea.xyz/life-cycle-of-a-citrea-transaction/



When do Citrea provers start proof generation and when do they inscribe it?

On why Kaspa failed to surpass Bitcoin and is likely to fail doing so.

denationalized

Kaspa uses UTXO commitments:
>[...] new nodes by default do not request historical data, rather, they sync in SPV mode, i.e., by downloading and verifying only block headers. [...] The node then requests the UTXO set from untrusted peers in the network, and verifies it against the UTXO commitment embedded inside the latest received header (technically, this is done against the latest pruning point). If those do not match, the node bans the sending peers, requests the UTXO set from new untrusted peers, and repeats the process. If those match, the node verifies that no unexpected inflation occurred by comparing the sum of UTXOs to the specified minting schedule, a comparison for which block headers suffice.