I assume your are hinting at the fact that structurally, each BTC tx needs to be verified independently (inclusion in a BTC block) vs in Zenon where the user's transactions form a chain (account chain) in the block lattice, so by verifying that the frontier momentum includes account block N we implicitly confirm block N - 1. The state transitions that interact with the embedded contracts are committed and verified as a receive block by the changesHash field. The placeholder changesHash in the momentum struct also made me raise an eyebrow.

Just did some light reading to try to understand the relevant concepts, so take this with a grain of salt as it could be utterly wrong. I started with the SPV section in the BTC whitepaper. I then looked at how go-zenon works. The momentum hash is derived from the data inside the momentum, including the hash of the MomentumContent, which is a list of the account block headers concatenated in a deterministic byte order. To verify that one account block was included, the SPV would need to download every account block header (currently capped at 100) and perform the same exact ordering and hashing to compare them. Normally, a SPV doesn't do that, it relies on a Merkle tree structure (or similar) committed to the momentum header. This would let you prove account block inclusion with a small merkle branch instead of fetching all headers, and making it computationally more costly. Bitcoin does this natively by including the Merkle root in its block header and serving the light clients a merkleblock directly. There's also some clever workarounds, particularly bloom filters and compact block filters, to address light client's privacy concerns and full node's unincentivized computation costs when light clients request this data. Either way, I guess I found those difficulties pumpum was talking about 😅