More generic ChannelID calculation

[ndzik]

Location

channel/backend.go

Problem

When implementing the Cardano backend, we realized that it would be very beneficial if we had the ability to pass auxiliary data for calculating the ChannelID of a given channel. E. g.:

We want to encode the fact, that a ChannelID is associated with an UTXO on Cardano. This is necessary for UTXO based chains to identify the correct channel instances and prevent channel cloning, because a valid channel will always contain a NFT which is associated with the spent UTXO. Having it encoded in the ChannelID, allows to easily identify valid on-chain UTXOs containing the channel state. This is because the UTXO in question would need to contain the NFT as a value and the spent UTXO as part of the channel state (on-chain).
With that information available we can validate the following:

1. The NFT contained in the UTXO's values is indeed the correct NFT
2. The UTXO used to create the NFT matches the derived ChannelID, which is also used as the on-chain address for the channel.

Point 1. and 2. allow an observer to validate and identify correct channel states without any additional information.

Proposal

// Backend is an interface that needs to be implemented for every blockchain.
// It provides basic functionalities to the framework.
type Backend interface {
	// CalcID infers the channel id of a channel from its parameters. Usually,
	// this should be a hash digest of some or all fields of the parameters.
	// In order to guarantee non-malleability of States, any parameters omitted
	// from the CalcID digest need to be signed together with the State in
	// Sign().
	CalcID(*Params, aux ...interface{}) ID

        // ... rest of interface definition unchanged.
}

Adding variadic auxiliary parameters to CalcID should make CalcID calls mostly backwards compatible. Whether or not aux should be of type interface{} is still up for debate.
We sadly cannot just update the go-perun versions on all backends without making changes, but this way should keep them very small and allow for a way easier time implementing UTXO based backends. This would take a lot of work off the EventSubscription, which currently would either need to know about the NFT before starting to listen for a channel, handle all possible events and let the user of the subscription handle with the mess or be dynamically changeable to listen to different threads of channel.
The EventSubscription can in most cases be set equal to the AdjudicatorSubscription for UTXO based backends.