Virtual Channels


#1

Hi there,

I think we need some more information about how Virtual Channels will work in terms of if they will keep working in case B closes a channel and about the amount of AE needed to transact with both.

Thanks


#2

Hi @Manel
We’re still flattening details regarding the virtual channels, so take my words with a grain of salt.

With the current approach being discussed: Alice wants to send tokens to Bob through intermediaries Ingrid1, Ingrid2 and Ingrid3. Alice tells Ingrid1 to lock X tokens inside her channel with Ingrid2, Ingrid2 locks Y tokens with Ingrid3 and Ingrid3 locks Z tockens with Bob, assumption is X >= Y >= Z. It is important to note that everyone locks different amounts but they all share a common entity for the channel with the same channel ID and same balances. They could lock more than this amount so Ingrids can charge some amounts for their service. From Ingrid1’s perspective, Alice has an opened channel with Ingrid2 and has no knowledge for Ingrid2, Ingrid3 and etc. Ingrid2 has knowlegde for Ingrid1 and Ingrid3. In current approach everyone has knowledge for Alice and Bob (the end users) so we can check their signatures in off-chain transactions if a dispute arises but we’re exploring approaches to remove it from the off-chain protocol. Once everyone has locked their tokens inside off-chain channels and all channels share the same vision of the vChannel’s ID, Alice connects directly to Bob so they co-sign the initial state. Note that none of the Ingrids has any knowledge for the internals of the state as Alice and Bob just sign a channel_create transaction having some initial state hash. Then Alice pushes it to Ingrid1 (as she has a channel with her) and this enters’ their off-chain state as the latest state of the channel (having just balance and some initial state hash), which does this with Ingrid2, which does this with Ingrid3 and as the channel open tx reaches Bob - the virtual channel is opened and they can safely start exchainging off-chain transactions in their virtual channel.

In the happy path: if Bob wants to close the channel Alice and Bob can provide states to their Ingrids as they would on-chain. The state with the greater round wins.

The funny thingy happens if one of the Ingrids is malicious or wants to close the channel with some other Ingrids but this is a bit longer to explain as it has a lot of corner cases. Short version would be: at the end, anybody can bring the off-chain dispute on-chain and let the block chain handle it on a protocol level via a force progress tx. With this in mind, we keep the same level of trustlessness the blockchain already provides.

Regarding the amount of AE tokens to be locked - this is a real economic issue all channels’ solutions face. The great thing about blockchain is that it is decentralized and the market will take care of this. At this point we can only speculate.


#3

@Dimitar.Ivanov can you share one graphic or a series of graphics that visualizes what you have written down? I want to get a better understanding how this approach could work.

so if I am understanding right the scenario of this example is as follows:

  • Alice has an open state channel with Ingrid 1
  • Bob has an open state channel with Ingrid 3
  • Ingrid 2 has open state channels with Ingrid 1 and Ingrid 3

Alice and Bob can then create a virtual state channel through Ingrid 1-3, correct?


#4

is it still planned to release support for virtual state channels with the upcoming hardfork?


#5

@marc0olo
The prerequisite for the example is that we have all the following channels on-chain already


            AI1 channel        I1I2 channel     I2I3 channel       I3B channel
             (on-chain)          (on-chain)       (on-chain)         (on-chain)


 +---------+       +-----------+     +-----------+     +-----------+      +-------+
 |         |       |           |     |           |     |           |      |       |
 |  Alice  |+-----+|  Ingrid1  |+---+|  Ingrid2  |+---+|  Ingrid3  |+----+|  Bob  |
 |         |       |           |     |           |     |           |      |       |
 +---------+       +-----------+     +-----------+     +-----------+      +-------+

If we have those Alice can open a virtual channnel directly to Bob using the existingly opened state channels on-chain.

Virtual channels are not going to make it in Fortuna hardfork.


#6

Sad. But at least I know there is ongoing work on the state channel client, which is essential for state channel aepps.


#7

We had to refactor huge portions of the off-chain protocol between participants so we have more solid base for building off-chain consesus. This is a prerequisite for stable virtual channels.


#8

thanks!

  • would it still always be possible to “exit” this scenario by publishing the last state to the blockchain at any time?
    • in other words -> would this scenario still be possible in a “trustless manner”?
  • do you have some sources to read more about virtual state channels?

#9

Yes, at any point of time, any participant would be able to initiate a solo closing sequence of either on-chain channel or a virtual one.

Details are yet not flattened out, so it is neither implemented, nor documented