Post History

For simplicity of description I assume below any interaction is a write interaction on all associated accounts.

First it is important to emphasize the following - while **A,B** have are each sovereign logic zones, it is consensus dictated that nodes running **A** also at times store account data belonging to **B**, and conversely that **B** nodes store **A** accounts data. The L1 regulates and is fully aware of this foreign storage allotment - though it maintains obliviousness to the actual data contents.

Now, a transaction composing two logic zones, **A, B,** will
only be legal to begin with if **A** is ensured by L1 to have all the required data from **B** necessary to compute it (and vice versa for **B**).

This can be ensured in several ways: 
1) L1 knows that **A** was already storing the latest data of B on the accounts relevant to the transaction
2)  L1 knows that A does not have the latest data required, but does already store a sufficient "covering layer" in the past of this latest data that can enable it to derive it by computing past transactions (of **B**, and of others). Notice that due to dependencies of past transactions, it is very plausible this covering layer contains other accounts from **B**, as well as accounts from other logic zones **C,D,E** etc. Any states **A** calculated through this "climb up", are also to be stored by **A** for consecutive transactions (upto some point in the future where it will be pruned). 
As a sidenote, the climb up to recent data incurs a computational burden on **A**, which must itself be regulated by L1.
3) If **A** does not even have a full "covering layer", this layer can be patched up with "witness data" revealing plaintext data which was committed to in a ZK proof sometime in the past.  It is the responsibility of the transaction issuer to supply this data (and a revealing proof for it) within the transaction , if required. The revealing is verified by L1, or the transaction is deemed illegal.


(3) could potentially raise some eyebrows - it is clear that if this happens all the time, then transactions eat up much bandwidth and the system suffers greatly.

First, it is for this reason exactly that vProgs are described with the built in separation to accounts - with the intention that account data be reasonable in size.
Second, The guiding logic behind this scheme is an empiric claim on the nature of transaction usage - an account recently composed with, has considerably more chance to be composed with again in the near term, than an account composed with a month ago. In other words, at any time period most transactions involve the same relatively few "hot" accounts constantly touched on. As the hot accounts data only need be revealed once to follow through with it, (3) shouldn't cause a bottleneck for regular usage patterns.