Mechanism for proposal ID generation

[manoranjith]

Location

[client]

Problem

Currently, we use the following mechanism for generating the proposal ID:

1. Encode all the parameters of the proposal, using perunio encoding into a binary format.
2. Hash the encoded data.

In #233, we have abstracted out the wire encoding component, so that different encoding formats can be used.
We also need to update the mechanism for generating proposal IDs, so that it is not dependent on a particular wire encoding format.

Proposal

There are two possible options:

1. We could add an interface in the wire package, that exposes methods for encoding proposals.
   These functions, will in turn use the wire serialization format that is set by the user. This can be perunio or any other protocol.

   type ProposalEncoder {
       LedgerChannelProposal(p LedgerChannelProposal) ([]byte, error)
       SubChannelProposal(p SubChannelProposal) ([]byte, error)
       VirtualChannelProposal(p VirtualChannelProposal) ([]byte, error)
   }
   

   Implications of this approach:
   In case of protocol buffers (the second wire serialization protocol, that we want to support), the serialized output is not canonical across different languages. Hence, serializing the proposal, could result in different binary outputs, when using implementations of protocol buffer library in different languages: Say, c and golang.
   References: 1, 2

   This would mean that, perun clients implemented in different languages, might generate different proposal IDs for the same proposal.

2. Looking at the fields in the channel proposals (here), most of the fields are already byte arrays. Apart from that, we have only one field of uint64 type and few fields of big.Int type.

   a. For the byte array types, we could directly hash them.
   b. For uint64, we could convert them to their binary representation (big/little endian), which is easy to do, consistently across programming languages.
   c. For big.Int or multi-precision integers, we could convert them to their decimal representation, strip the leading zeros and hash the resulting string.

   Implications of this approach:
   As we directly use the byte arrays and define custom canonical formats for the other types (uint64, multi-precision integer), this mechanism will generate the same ID for a given proposal, across different programming languages.

   However, this introduces a small overhead of having to implement this across different implementations and maintain them.

Resulting properties:

In case of 1: Since, different language implementations could produce different outputs, it may not be possible for a receiving party to verify if the proposal ID was generated correctly. The receiving party will have to trust the sender.

In case of 2: It is possible for the receiving party to verify.

[manoranjith]

@matthiasgeihs, I have summarized both the approaches that I had proposed for generating proposal ID. You can have a detailed look into them. Depending upon what properties are desirable for proposal ID, we can choose one of them.

[matthiasgeihs]

A few comments.

If we choose to go for approach 1, I suggest the following encode interface.

type ProposalEncoder {
    Encode(p ChannelProposal) ([]byte, error)
}

I checked the protocol and source code. It is not necessary for the ProposalID to be reproducible on the receiving end. Its main purpose is to let the proposer identify a response to its proposal. The proposal receiver can simply copy this ID to its proposal response and does not need to care about the value itself.

We could replace the proposal ID generation with a random nonce. This would eliminate the disadvantages of the methods proposed above (1) artificially exposing additional encoding methods, 2) having to implementing a custom encoding for ProposalID).

[manoranjith]

@matthiasgeihs Okay. If is not necessary for the proposal ID to be reproducible on the receiving end, I think, the alternate approach (of just using a nonce) that you have suggested looks like a better one.