Directly open heads

[ch1bo]

Why

After the incremental de/commits are implemented we noticed there is room for the protocol simplification. There is no need to have the commit, collect and abort transactions if the Head protocol would start immediately in the Open state and then parties could start committing (and decommit) funds to a directly open head.

Not having an initialization phase will avoid issues of "non-abortable heads" #699, remove the bottleneck of collectCom and abort transactions (they are limiting how many parties we can support right now) and an overall simpler state machine, at the cost of potential congestion if multiple participants want to commit at the same time.

What

Init-ing a head used to mean all participants get the inital output they need to spend in the commit transaction which then get collected in order to open a Head. If we are in the Open state right after initializing the protocol we can just directly commit funds to a running Head in order to be able to transact on L2.

In the same manner while the head is open we can also choose to decommit some funds.

This means we can get rid of code and tests related to the init, commit and collect transactions and observations. This should slim down the code and make it easier to maintain but also make the Head protocol a bit easier to reason about.

Before doing these changes we need to talk to researchers and see if they see any potential flaws in this new design.

Open questions:

• Previously init tx was producing outputs that contain the PT tokens for the users to spend into commit. How would the workflow look like without this step? We would need to produce the vHead output with all of the needed tokens so probably we would need to re-purpose the vInit script (or create a new one) to do that on start of the protocol.

How

We need to remove:

• Client inputs that are no longer needed
• Server outputs that are no longer needed
• Off-chain transaction creation and observation for init, commit and collect
• vInitial and vCommit scripts
• Related tests
• Related benchmarks and tx-cost calculations

[ch1bo]

Changed title and edited the description as fanout is not avoided and still required in this model. So this is really only about removing the commit phase at the cost of forced sequencing of commits.

Writing about this, I realize this could be avoided as well by having n head outputs per head, i.e. one for each participant. However this would complicate close transactions as they would then need to collect all those outputs (like the collect does now).

[GeorgeFlerovsky]

@ch1bo This is a really cool idea. If I understand it correctly, it would remove the CollectCom bottleneck from Hydra and make opening/committing much more flexible. Very beneficial for L2 dapps IMO.

Question: I don't see a contestation mechanism in the diagram for Direct Open; how do you deal with the scenario of L2 consensus breaking down?

[ch1bo]

Question: I don't see a contestation mechanism in the diagram for Direct Open; how do you deal with the scenario of L2 consensus breaking down?

@GeorgeFlerovsky That's actually a typo in the tikz I used to throw together that slide. It's also indicated by the crossed out sentence.

So this feature would not change anything on the closing/contestation procedure and only get rid of the commit phase.

[GeorgeFlerovsky]

Question: I don't see a contestation mechanism in the diagram for Direct Open; how do you deal with the scenario of L2 consensus breaking down?

@GeorgeFlerovsky That's actually a typo in the tikz I used to throw together that slide. It's also indicated by the crossed out sentence.

So this feature would not change anything on the closing/contestation procedure and only get rid of the commit phase.

Right, that's what I thought it was. 👍

[ch1bo]

@noonio Updated the Why and mention how this is an alternative to #699, which I'm superseding now.