Another set of actors to keep in mind in all of this is light client servers - nodes that store the full state of a (shard, EE) pair and serve Merkle branches to anyone who wants to read the state (as well as storing history/receipts). Clients would establish connections to these servers and ask for Merkle branches for specific history or state in exchange for payments through a channel. Because any user will be a light client in almost every shard, this class of actors becomes very important. They are also a natural class of actor to serve as a relayer, and they can charge epsilon for the service of relaying at time of receiving the transaction, so it doesn’t matter if block producers just take their packaged tx and redirect the reward to themselves.
Currently, there are few light client servers, but if we set up the infrastructure, in the eth2 world there could be many. Potentially validators could also be light client servers, though really any functionality that involves being always online and storing the chain (eg. on-chain DEX arbitrage bots) could benefit from bundling with being a light client server 
Will need to think more about this idea of sync calling between different EEs.