I’ll emphasize again that the central challenge is really is primarily one of consensus which is difficult to solve in a privacy preserving way without more advanced cryptographic tools. Fundamentally, chain A is allowing chain B to mutate some state on chain A, and chain A needs to ensure that any invariants (e.g. token supply) remain preserved. IBC accomplishes this with “escrow” that limits the damage that can happen if chain B fails in some way.
For example, if we assume chain A and chain B are fully synchronized (e.g. validators run full nodes of the other) then avoiding the escrow question entirely and simply checking that the invariants are preserved on chain B directly, step 3 of the “IBC” could be done in a privacy preserving way. If the shielded state transition system is the same on chain A and chain B, then after steps 1 and 2, chain A (or B) receives confirmation that chain B (or A) has successfully completed its IBC steps, then chain A simply verifies the state transitions of chain B. This only works because the entire token supply of chain A is “at risk” if chain A doesn’t fully verify B. Of course, this defeats the whole purpose of IBC since no scaling benefit is achieved and also chain B is fairly restricted.
We can hypothesize some different ways of accomplishing similar things. For example, chain A/B needs to verify the final state of B/A, theoretically allowing some kind of rollup or recursive proof of chain B’s state. Of course, careful analysis is required because chain A also needs to meta-verify that chain B’s state transitions always preserve A’s invariants, which is probably difficult to do in general.
So let’s return to the escrow idea. We substituted light clients for full synchronization, and instead protected chain A with escrow, which is a shared mutable state (thus creating the cryptographic difficulty). A natural attack would be to use MPC, and indeed MPC is arguably much more mature and efficient than FHE based techniques. The MPC model is rather unfavorable because on the real internet participants can be slow, faulty, honest-but-curious, adversarial, etc. and a potentially high number of MPC rounds presents its own challenges. In a world where single-party computation is relatively cheap compared to interactivity these tradeoffs matter a lot.
To finish, I’d like to consider some additional crazy ideas for escrowing. For example, when bridging a 64-bit amount of token T from chain A to B, the bits encoding value are committed in 64 different commitments on chain A, effectively escrowing each bit independently. Then each tx on chain B must (verifiably) forward the trapdoor randomness to the next user, and unescrowing on chain A requires the trapdoor. At minimum this is safe for chain A, and assuming consistency of chain B, prevents double-unbridging (each user on chain B can unbridge to A only the amount they control on B)
So what’s the problem with this? Well, it suffers the “faerie gold” attack - a user on chain B, having held some token for a while, can deny future holders of that token the ability to unbridge back to A - the attacker unbridges some other balance of the same token using the first trapdoor escrow, using the fungibility of the token. So chain B has to cryptographically link an unbridging to the specific trapdoor used (which seems reasonably possible)
This also has some privacy leakage, because anyone who ever sees the trapdoor can now tell when that trapdoor is used to unbridge some of this token in the future. This could possibly be mitigated by occasionally “refreshing” the trapdoors.