You’re correct that moving the balance of beacon eth between EEs on the beacon chain would not be a synchronous call and requires a crosslink to form and a receipt to absorb from a shard/EE that pegs to it. Even if we assume this proposed design pegs all fees to beacon eth, this would still simplify the proposal by just generating one account balance per EE/slot for the proposer vs. multiple receipts generated for each submitted transaction package on each EE. I also am on board with agreeing on the right terminology here as well to distinguish balance transfers of beacon eth and stateroot updates for shard eth.
However, I would challenge the assumption that fees would only be paid in beacon eth. I’d also challenge the assumption that pegged beacon eth even needs to be tied to an EE at all. It’s difficult to predict the general trajectory/future of how EEs will form, but here are a few scenarios that could arise:
1. We peg/bind beacon eth through a shared EE or even token EE (think ERC-20 implementation)
This scenario is interesting. We could have a token EE that manages deposits/withdrawals of beacon eth and also supports generating other tokens. If we move in this direction and synchronous EE calls are supported within a shard, then beacon eth and other tokens can be bound/shared collectively between other EEs. For example, the eth 1 EE and the community supported eth 2 EE can now transfer value between each other fluidly and synchronously. There would be no need to move pegged eth between the two EEs since the token/shared EE already pegs everything and can be withdrawn directly to the validator account on the beacon chain.
2. An EE doesn’t peg itself to beacon eth
Of course, pegging/backing to beacon eth make sense for the eth 1 EE and the subsequent EE the community/ecosystem stands behind. However, we can’t be sure that the canonical/main store of value in addition to fee market in other EEs will be centered around beacon eth.
Anyways, it sounds like we’re likely on the same page, but wanted to clarify the various scenarios. If we do not enforce EE fees to beacon eth, then using the fee market EE to synchronously call into each of the EEs can be pretty powerful here.