Escape from the peers misconfiguration trap

[pgrange]

Problem

Before initializing a head, each hydra node operator must configure their instance with all the other futur peers' verification keys (cardano and hydra verification keys). More often that not, someone make a mistake during the operation making the opening of the head impossible and loosing fuel in the process.

Impact

When the problem happens:

• the node initializing the about to be aborted head looses funds as wasted fuel
• all the operators waste time analyzing the issue and double/triple checking everybody's configuration
• important delay in the head opening is incured as each operator has to do the checking

When the problem does not happen and the head is successfully open it has an impact anyway:

• each operator must get each others keys without any error or change during the process
• all the operators tend to double-check everything before opening the head, making the process heavier
• important delay is incured during the process because no operator can change their keys after they have shared them with everyone else, meaning they will formally or informally implement some kind of changes frozen period to ensure all is 100% stable

Standard

We should define what should be the standard cost and delay for operators to open a head. That way, we could benchmark our current process. Here I will propose the following standard based on previous observation and... intuition:

• one operator should have to share their verification key only once
• one operator should be able to easily spot and fix a misconfiguration of their node without loosing any funds
• one operator should be able to easily spot and fix a misconfiguration of their node without loosing any funds
• delay for opening a head with 4 members should be less than an hour, including verification key exchange
• hydra tooling must not make it easier for an attacker to deceive an operator by using the attackers verification key instead of a legit peer key. If possible, it should make it harder. Here, easier and harder mean compared to some out of bounds process the operators have in place to exchange their keys, hence their identity.

We do not meet this standard now. When involving 4 different people/operators we often took more than an hour to successfully open a head (especially if we include the exchange of the keys in the process, and I think we should) and lost some fuel.

We did not have any deception issues compared to out of bounds exchange of keys... but we did not have that much tooling in place.

probable Cause

Step 1 is manual and error prone:

• Operator 1 must broadcast their verification keys with Operator 2, Operator 3 and Operator 4.
• Operator 2 must broadcast their verification keys with Operator 1, Operator 3 and Operator 4.
• Operator 3 must broadcast their verification keys with Operator 1, Operator 2 and Operator 4.
• Operator 4 must broadcast their verification keys with Operator 1, Operator 2 and Operator 3.

When everybody has shared their key with everybody, enter step 2 which is also manual and even more error prone:

• Operator 1 configure the verification keys of 2, 3 and 4 on their system.
• Operator 2 configure the verification keys of 1, 3 and 4 on their system.
• Operator 3 configure the verification keys of 1, 2 and 4 on their system.
• Operator 4 configure the verification keys of 1, 2 and 3 on their system.

Probable cause 1: cumbersome and manual process

At that point in time we have a matrix a 4x3 entries (3 peers verification keys configured on each of the 4 nodes).

Probable cause 2: Hydra does not offer any help to validate this configuration

Shall any of these 12 entries be wrong, opening the head will fail, fuel will be lost and time spent to fix the situation.

expected Result

We will know if we have found a valid solution to this problem if we meet the standard defined above.

[pgrange]

From Hydra: Fast Isomorphic State Channels section 3.1:

Each party then establishes pairwise authenticated channels to all other parties or—if this is not possible—aborts the protocol setup. The parties then exchange, via the pairwise authenticated channels, some public-key material.

[pgrange]

Another misconfiguration problem is if nodes don't have the same protocol parameters.

The, currently, nothing will prevent them from opening a head but, of course, transaction in L2 will fail and the head will be stuck.

It could be hard to figure out that this is the root cause of the problem.