Multi-backend: Specify intended chain ID(s) in channel Params/proposal, clarify architecture.

[RmbRT]

1. It is unclear where the channel is deployed from the proposal and channel params alone. Do we use the same channel ID on multiple chains? If so:

   • Channels should have the chain IDs as an array in their parameters, so that when restoring a channel upon node restart, it is clear where the channel lives.
   • We then also need a scheme for coming up with a global blockchain identifier in the first place.
   • Optional: contracts should check whether the chain ID array in the params contains the contract's chain's ID. But we need to rework the contracts anyway to support the new encoding of the channel parameters.

2. How are L2 addresses handled on cross-chain channels? If we use incompatible crypto for L2 addresses, we will be unable to construct a channel for both chains, as the chains are unable to verify the signatures or parse the L2 addresses. If we have incompatible L2 crypto, we would have to construct two channels with differing channel IDs (due to differing Params encoding), and those cannot be updated atomically anymore if they require two sets of signatures. This would make cross-chain swaps impossible.

   • The way I see it, we should finally enforce a single off-chain crypto implementation, at least for cross-chain channels. Otherwise, I see no way to have secure and atomic commitments to a new channel state, as the proposer has to sign for both chains, but the other party may just sign the state update for one chain and withhold the signature for the other chain, allowing him to break atomicity of asset updates.
   • We need to properly document the high level concept for multi-chain channels and also how they are realised.

[matthiasgeihs]

A channel ID must be globally unique. A channel by itself is not deployed on a chain. The channel references assets which are held on certain chains. The respective chains are encoded in the asset identifiers.

Does that clarify your issue? @cryptphil should be able to elaborate further.

[RmbRT]

So for cross-chain channels, we have a single channel ID that is registered on both chains? Then we have the problem that both chains don't necessarily support the same L2 addresses and signatures. Initially, uniform L2 crypto was never a requirement, but now it seems to be.

[matthiasgeihs]

I think it's somewhat misleading to call them cross-chain channels to begin with. It suggests that asserts are crossing the networks, which is not the case. It's just a matter of linking state changes across chains. Anyhow.

Yes, a single channel ID. You can only make this work across chains if they support the same encoding and signature algorithms and so forth. At least as far as I thought this through.