VSC yellow paper #382

velzevur · 2019-07-25T15:17:36Z

For some time now @uwiger and I had been describing our vision for Virtual State Channel.
This PR is the current view of it, once we all agree upon it, we will share it to the forum where people can discuss it even further.

The goal is defining the on-chain protocol.

uwiger · 2019-07-26T09:06:43Z

I will withhold my review, since I was a co-author of the document. :)

tolbrino

Excuse the lack of detail in my review as I'm still finding my way through SCs. Until then here is some high-level feedback.

The proposal reads more like a blog post and less like a specification / technical design. If that is not the intention it should be reworked to be more formal and structured.

I would like more step-by-step visuals for the explanations of setup and error cases. VSCs add another layer of complexity to the interaction between parties using SCs. Thus, visuals would really help making the processes clear.

Regarding the approach: VSCs are described as the means to realize soft-realtime use-cases using SCs. The proposal doesn't give a explanation how the use of VSCs would work end-to-end. This would be useful for an example use-case because lowers the abstraction level for the reader quite a bit.

velzevur · 2019-07-29T07:55:42Z

The proposal reads more like a blog post and less like a specification / technical design. If that is not the intention it should be reworked to be more formal and structured.

Yes, as intention is to be shared to the community so it can be discussed there. Later on we will have a better more strict and technical documentation.

Regarding the approach - the goal is to have a solid shared understanding regarding on-chain dispute mechanisms, so we can bake the in the on-chain protocol. The details of tthe off-chain protocol are not yet cleared out and are outside of the scope of this document.

sennui · 2019-07-26T20:22:52Z

channels/VSC.md

+
+Each channel has an ever changing state. It is represented by a set of MPTrees
+that hold accounts, contracts and contract calls. This set of MPtrees can be
+treated as one big MPTree that has a root hash. This is what we call a


all trees like in full node state? (oracle, aens, etc.)

yes, but names and oracles are empty

gorbak25

There should be a TX dedicated for force progressing VSC operations - more info in devchat.
The only case in which the VSC state should be exposed is when on-chain forcing a force_progress_tx inside the VSC - more info in devchat. Additionally the AI, IB offchain state can remain mostly private.
Channel creation should sometimes be force progress-able - For instance Alice sends to Ivory a channel create TX and then Ivory applies the TX to the AI channel but not to the IB channel - In this case Bob or Alice should be able to perform a VSC force progress operation.
Onchain VSC force progress operations could in some cases move the channel onchain(If Ivory cheated once then she may do it again). The proposed channel_vsc_force_progress_tx contains enough information to move the channel onchain - after a move was done we need to wait for disputes comming from Ivory as the channel_vsc_force_progress_tx may not be based on the latest state.
Sometimes we may want to change the intermediary - this can be done if the parties cooperate. I'm not sure if this will be useful.
I'm not sure how disputes should be handled in the multi-intermediary VSC, If we stick to the VSC in VSC model then I see how can we guarantee security.
The off chain FSM should check if an VSC can be established - if so then while opening a channel the client should be able to chose between creating an onchain SC or a VSC - this would increase usability drastically.

velzevur · 2019-08-04T13:03:10Z

1. There should be a TX dedicated for force progressing VSC operations - more info in devchat.
2. The only case in which the VSC state should be exposed is when on-chain forcing a force_progress_tx inside the VSC - more info in devchat. Additionally the AI, IB offchain state can remain mostly private.

This is true, I will amend the file with it.

3. Channel creation should sometimes be force progress-able - For instance Alice sends to Ivory a channel create TX and then Ivory applies the TX to the AI channel but not to the IB channel - In this case Bob or Alice should be able to perform a VSC force progress operation.

In this case Ivory will have already commited some tokens to the VSC in Alice-Ivory SC, so Ivory has the financial incentive to open the same VSC in Ivory-Bob. If Bob rejects it - Ivory shall close the VSC in Alice-Ivory VSC. Until Bob gets the virtual channel creation in Bob-Ivory SC, then Bob can not proceed using the VSC in a safe manner.

4. Onchain VSC force progress operations could in some cases move the channel onchain(If Ivory cheated once then she may do it again). The proposed channel_vsc_force_progress_tx contains enough information to move the channel onchain - after a move was done we need to wait for disputes comming from Ivory as the channel_vsc_force_progress_tx may not be based on the latest state.

I find this a cool optimization but it is debatable if it is needed for the initial version

5. Sometimes we may want to change the intermediary - this can be done if the parties cooperate. I'm not sure if this will be useful.

Indeed useful and will make the netwok much more dynamic and resilient. Since it is outside of the scope of the on-chain protocol, it is outside of the scope of the document.

6. I'm not sure how disputes should be handled in the multi-intermediary VSC, If we stick to the VSC in VSC model then I see how can we guarantee security.

I think it would be the same as everyone can take care just for themselves.

7. The off chain FSM should check if an VSC can be established - if so then while opening a channel the client should be able to chose between creating an onchain SC or a VSC - this would increase usability drastically.

FSM is out of the scope of this document.

channels/VSC.md

Co-Authored-By: AleksandarFilipov <aleksandar.f@gmail.com>

channels/VSC.md

AleksandarFilipov · 2019-08-06T13:30:29Z

Upon VSC creation Ingrid must have sufficient amount of AE:s, the same goes when Alice/Bob does a deposit (this would strain Ingrid).
Upon creation of a VSC Alice and Bob are re-allocation a portion of his/her AE to the new VSC. These were previously allocated on SC Alice-Ingrid and Bob-Ingrid. This would present some kind of risk to Ingrid?

Co-Authored-By: AleksandarFilipov <aleksandar.f@gmail.com>

velzevur · 2019-08-06T13:38:42Z

1. Upon VSC creation Ingrid must have sufficient amount of AE:s, the same goes when Alice/Bob does a deposit (this would strain Ingrid).

Yes, this makes sure the channel is not having more tokens off-chain than on-chain. Otherwise it would be undisputable on-chain.

2. Upon creation of a VSC Alice and Bob are re-allocation a portion of his/her AE to the new VSC. These were previously allocated on SC Alice-Ingrid and Bob-Ingrid. This would present some kind of risk to Ingrid?

The goal is Ingrid to be safe in any case, including the one where Alice and Bob are not cooperating and refuse closing the channel. Then Ingrid can initate a closing on-chain and let them provide newer states than the opening one.

channels/VSC.md

AleksandarFilipov · 2019-08-06T15:07:01Z

Closing the VSC would mean that we the go back to the state before opening. Difference being that the AE:s between Bob and Ingrid are distributed differently. The same same does for the AE:s between Alice and Ingrid. Critical is that Ingrids AE:s in the two SC equal the same amount as before the VSC.
So if Alice opens a VSC (with bob over Ingrid) this would mean that there is a withdrawal from the SC (between Alice and Ingrid). How is that reflected in Alice-Ingrid SC?
Assume that Alice-Ingrid SC could operate at the same time as Alice-Bob. What kind of complexity does this introduce, given that the allocation changes for the carrier SC. Same reasoning goes for VSC upon other VSC.
Fuzzy one, https://github.com/aeternity/protocol/pull/382/files#diff-27f917ebdc0662bc956375a713a87123R386 It would make sense to try and distigish the term on-chain when its acutally referrs to Ingrid or node communication.

channels/VSC.md

uwiger · 2019-08-06T17:28:50Z

channels/VSC.md

+  * a co-authenticated VSC snapshot
+  * a co-authenticated VSC settle
+  * a co-authenticated VSC mutual close
+  * unilaterally authenticated dispute. Those also provide a context of the


a unilaterally ...
context for ...

uwiger · 2019-08-06T17:29:55Z

channels/VSC.md

+  applied on top of the `poi`
+* `round`: SC's next round
+
+Note that this allows force progressing of both contracts in VSC and force


force-progressing

uwiger · 2019-08-06T17:30:34Z

channels/VSC.md

+progressing a VSC inside a VSC.
+
+From now on we will use force progress in the context of VSC meaning a Virtual
+State Channel Force progress transaction - `channel_vsc_force_progress`.


Force Progress

uwiger · 2019-08-06T17:30:57Z

channels/VSC.md

 ##### Example

 Alice wants to close her Virtual State Channel with Bob, but Bob refuses. Alice
 produces a solo update in her on-chain State Channel with Ingrid initiating a
 solo-closing sequence of the Virtual State Channel. If Ingrid refuses this,
-Alice can force it on-chain.
+Alice can force it on-chain using `channel_vsc_force_progress.


missing ending backtick.

uwiger · 2019-08-06T17:31:36Z

channels/VSC.md

-next Ingrid-Bob off-chain state. The newly produced Ingrid-Bob state has in its
-state the VSC's.
+refuses to co-authenticate the next state, Alice can produce an off-chain
+`channel_vsc_force_progress` which is similar to force progress and bring it


..., which is similar to force progress, ... (commas)

Co-Authored-By: AleksandarFilipov <aleksandar.f@gmail.com>

Co-Authored-By: Ulf Wiger <ulf@wiger.net>

knarz

I agree with Tino's statement, that this doesn't read like a specification. So, I'd say that in the current form it does not belong into the protocol—at least not into the master branch.

Beyond that, with the earlier comments in mind, the approach seems fine but I'd to withhold final judgment until we have something closer to a specification.

knarz · 2019-08-15T20:17:05Z

channels/VSC.md

+software will run in different contexts.
+
+With this in mind, in order for us to explain in detail the nuts and bolts of
+Virtual State Channels we must first dive deep into on-chain State Channels. I


Switching from we to I

knarz · 2019-08-15T20:18:45Z

channels/VSC.md

+treated as one big MPTree that has a root hash. This is what we call a
+`state_hash` of a channel and it identifies the channel's state at a certain
+point of time. Since in essence the off-chain world is detached from the
+on-chain world - we don't measure points of time with blocks but rather with


knarz · 2019-08-15T20:21:04Z

channels/VSC.md

+as to _when_ they were produced: we must be able to order state changes. Thus we
+also have an increment-only value we call `round`: it is the index of the round
+of updates, starting with [1 at channel creation
+time](https://github.com/aeternity/aeternity/blob/16ecd302e60f599bfe3cc5f5cf0f7ea5ea336874/apps/aechannel/src/aesc_create_tx.erl#L304-L306).


Link to source code is irrelevant, imho

knarz · 2019-08-15T20:33:11Z

channels/VSC.md

+
+That would mean that no transaction is posted on-chain when opening the Virtual
+State Channel, and it is active and safe to use as soon as all three parties
+have agreed upon it. The proposed solution results in using Ingrid as on-chain


The proposed solution results in using Ingrid as on-chain State Channels use the on-chain. This can probably go since the next sentence says the same thing

Initial commit

515970a

velzevur requested review from tolbrino, uwiger, knarz, gorbak25 and AleksandarFilipov July 25, 2019 15:17

Reformat text

24542a1

velzevur force-pushed the VSC_proposal branch from 064c44e to 24542a1 Compare July 26, 2019 10:42

tolbrino reviewed Jul 26, 2019

View reviewed changes

sennui reviewed Jul 29, 2019

View reviewed changes

gorbak25 reviewed Jul 30, 2019

View reviewed changes

Describe VSC forced progress structure

efc70fc

AleksandarFilipov reviewed Aug 6, 2019

View reviewed changes