What is Kaspa pruning?

According to Shai Deshe Wyborski: “Pruning” is the idea that it is unreasonable, unscalable, and ultimately centralized to require all full nodes to store all historical data indefinitely. “Rollups” are the idea that it is unreasonable, unscalable, and ultimately centralized to require full nodes to process the entire logic of the entire ecosystem just to verify its consistency. In both cases, finding an alternative that is comparably secure is very hard, but not impossible. In both cases, teams developing Kaspa and over Kaspa managed to provide such alternatives (standing on the shoulders of preexisting pieces of the puzzle like MLS and ZK). Immutable ledgers and on-chain computation are not the defaults. They are just compromises made due to lack of better solutions. Preferred just because they are the most conceptually simple solutions (despite this simplicity just delegating infinitely deep problems to other components, e.g. regulating processing via gas fees that are provably impossible to compute in the general case). A reality that has since changed, despite some people insisting to stay behind. Source: https://x.com/DesheShai/status/1895492007721685181

According to @KaspaFacts via X: Kaspa separates the Application Data and Consensus Data (at the pruning point). Application Data (UTXOs, account balances, and contract state) As old UTXO’s are used up, they are no longer retained. Consensus Data (block headers) MLS adapted for DAG provides PoPoW without keeping ALL headers. Application Data only keeps living information. Consensus Data only keeps enough historical information to prove the work that has gone into the DAG up to the pruning point. Transactions go in the body. All the rest of the information about the block goes in the header (Parent, Mergeset, Miner, Links to previous blocks, etc.). The header is then hashed with a nonce to create a hash that is at least of the required difficulty. Source: https://x.com/KaspaFacts/status/1895521775255241006