What about the total processing time in case of a long chain/cycle of transactions?
For example, an account could generate a dummy address on another shard to send ETH back and forth using encumberments.
Now if that account wants to send a real payment, it can create another receipt for the desired address, but it will take possibly a long time for funds to arrive. This means that the wallet software should be aware of the process duration and set a threshold for the maximum expected waiting time.
It seems to me that, over time, the centralised solutions to the slow cross-shard transactions problem could emerge. Consider this:
Alice from shard A wants to send 5 ETH to Bob on shard B. Instead of using a crosslink, she can send 5 ETH to the “messenger” contract on the same shard. The contract owner notices that and sends 5 ETH from the messenger account on shard B to Bob.
The incentive for the messenger is additional fees provided by Alice.
The reason for sending to contract on shard A rather than EOA is that maybe protection of funds can be guaranteed by automatically sending back ETH if the proof hasn’t been provided that transaction was really sent on shard B.
This proof can be presented in the form of a periodic cross-link with a long period (to gather more transactions), e.g. every 10 slots, which contains aggregated proofs for multiple transactions from shard A to B. If the proof is not presented in the desired time period, e.g., 20 slots, the funds will automatically return to the owner.