Delayed state execution in practice

It seems like this adds considerable overhead compared to a simple casper light client.

To find the current state root, light clients must download claims for each block starting from the last state root they are sure of. Else, as claims are conditional on the previous state root, if there is a “break” in the chain somewhere, claims after the break are worth nothing. This makes light client sync proportional to the number of blocks they were offline, rather than constant (as the light client linked above).

Also - what’s the impact on weak subjectivity? If a client is coming online for the first time and just has a recent block hash, unless they start from the genesis and work their way to the current state root on that block, any claims on this block’s state root are worthless to them (again, because there could be a break in the chain somewhere that they have to check for). A simple solution to this is including the state root in the weak subjectivity format.

Adding unconditional claims about state roots (similar to what the simple light client w/ finalized blocks) would seemingly address both of these concerns for a bit more complexity.