[Vitalik Buterin] so, here's the right way to think about it
[Vitalik Buterin] on every shard, you have a "shard state", call it s[i]
[Vitalik Buterin] the state transition function takes as input s[i] and a collation on shard i and outputs s'[i]
[Vitalik Buterin] note that post-serenity the goal is that all transactions are valid; transactions that do stuff that we'd consider wrong like spending money that doesn't exist simply have no effect
[Vitalik Buterin] this creates a nice clean separation between state transition computation and data availability verification
[Vitalik Buterin] now, a "collation object" would be of the form (prevstate, collation_root, poststate)
[Vitalik Buterin] a collation can only be invalid if either (i) the collation root points to data that's malformatted, or (ii) the poststate does not follow from the prevstate
[Vitalik Buterin] there is cross-shard communication, but that deliberately has a delay
[Vitalik Buterin] specifically, we expand the state transition function slightly
[Vitalik Buterin] so it also has access to *receipts created in other shards from the previous dynasty*
[Vitalik Buterin] this is important
[Vitalik Buterin] as it means that the only cross-shard state that state transitions can depend on is state that is already finalized
[Vitalik Buterin] as dynasty changes imply finality
[Vitalik Buterin] in practice, this means that cross-shard communication will have a lag of ~30-60 min