A braindump of all things crescendo, what’s included, what are the benefits, etc This might contain many details, so hold tight. Increasing the block per seconds from 1 to 10 bps while keeping block capacity ~fixed (more on that later). Throughput: obviously, transaction throughput increases. How much? almost tenfold but not exactly 10x. Having more parallel blocks increases the collision rate to some degree. On TN10 and with current mempool txn selection policy, we observe ~80-90% efficiency (i.e., 80-90% of the txns are unique). If the mempool gets over congested and demand significantly exceeds capacity, this efficiency value goes towards 100%. So to conclude, TPS is increasing 8-9x. The missing info is mainnet average DAG width post-activation vs. today. Mempool policies can be finetuned in the coming future without a hardfork based on such real-world data. Frequency: average block time (=interval between blocks) is being reduced from 1 second to 100 milliseconds. This means blink-of-an-eye txn inclusion time. A transaction need not propagate to the whole network in order to be included; for instance, it can reach miners in its continent in 50ms and get mined after 200ms. The frequency also decreases post-inclusion confirmation times due to the increased density of the mining sampling process. Not to say confirmation times decrease tenfold, because they are now dominated by block latency which hasn't changed. Rather, by back-of-the-envelope calculations, they have improved 30% (for the advanced: the tail of the Poisson governing worst-case DAG width diminishes faster, thus K can be set relatively lower, from 18 (1bps) to 124 (for 10bps) and not to 180 as one might expect). Block parallelism: block parallelism increases with the block rate, and that, contrary to what you might think, is good. Despite collisions being slightly increased due to block parallelism, parallelism is crucial for creating a more fair system. It means there isn't a monopoly of a single winning miner per round, but rather blocks must compete and make wise and competitive decisions within the latency round. The implications can be huge and far-reaching. Oracle systems and MEV kickback auctions are some of the preliminary efforts. Going more into this is out-of-scope. I also need to justify why finance is becoming more relevant post-crescendo... assuming that's the case, I think that even without implementing MEV kickback designs explicitly in consensus (yet), the mere intra-round “chaos” of the parallel DAG at 10 bps will already make economic manipulation much harder than in other, leader-based systems. Other changes included in crescendo. How do I start, there's so much. KIP-9 is integrated into consensus, baking our unique state bloat solution inherently into the system. By the way, we call this “harmonic” sub-protocol the name STORM (for STORage Mass). In the process, KIP-9 was extended to include UTXO storage plurality (i.e., taxing a UTXO which consumes more storage appropriately), making it more futureproof. KIP-10 adds support for basic covenants and additive addresses. KIP-13 regulates transient storage requirements more strictly. Smart contract-related changes: KIP-14 enables payloads, allowing txns to carry arbitrary data (e.g., smart contract function calls). KIP-15 is a technically minor upgrade -- comprising one line of code -- but enables a conceptually meaningful feature, allowing nodes to archive only transactions and prove their sequencing and acceptance trustlessly. This is significant for allowing pre-zk era L2 nodes to store and prove full SC execution to new syncers at a reasonable cost—hence effectively making such systems possible right after crescendo. The change proposed is a tiny subset of the zk design proposal (see Kaspa research forum—based rollups design posts) where such a mechanism was proposed as a necessary requirement for zk systems to operate over Kaspa, and turned out to have significant value also pre-zk. Overall, this means that preliminary SC L2s are possible over post-crescendo Kaspa (or Kaspa 2.0 as @hashdag refers to it internally) with sufficient trust models. Other things I wanted to write about but will wait for another time: survey the increased-yet-limited hardware costs of this upgrade, why I conjecture the mainnet DAG width will not grow tenfold post crescendo (hints: the continent claim above; i.e., locality in the P2P net), and more. Please ask about anything unclear or that requires elaboration.