Nov 4, 2024

Transactions are not written in order. Inputs are never assumed to exist or to be unspent (adherence to the milestone proves that prevouts exist and are unspent). Under milestone, the performance advantage comes from extreme concurrency. We can and do download the entire chain concurrently, though we generally configure to break it up into 50k block chunks which complete before moving to the next. This chunking improves data locality (query perf) and ensures we don't get block 1 last (which significantly delays validation in the concurrent validation scenario). Block height is not the criteria for a milestone (he may just be speaking loosely). The "utxo set" is proven to be valid under the assumption of the milestone (i.e. that the milestone represents a valid branch). So there is no difference whatsoever in the security model of a milestone and assume valid. In fact I formerly assumed theirs worked the way ours does. But now I can see that the architecture doesn't really lend itself to these optimizations. Skipping block validation checks doesn't amount for any of the performance difference, which is visible from the fact that we are unaffected by the lack of SHANI until we become CPU bound. Skipping the confirmability checks during download (and validation) is a significant performance advantage, as it is what allows parallelism. However, we can fully download, validate, check confirmability, and confirm the entire chain in 6.2 hours on a machine that takes BC over 24 hours (see above). So it is really not the case that skipping these checks during a milestone run is the basis of the performance advantage. We just don't perform unnecessary checks. The true performance advantage comes from massive parallelsism.