Virtual State Channels

Protocol Features & Updates State 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.

1 Like
3

@dimitar.chain 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?

1 Like
4

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

5

@marco.chain
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.

3 Likes
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

2 Likes
10

This all sounds very interesting and I wonder whether it would be a solution to a use case I’m working on related to organisation management via blockchain. The problem is that organizations deal with both public and internal data. For the public data it’s easy: It can be on-chain.

The internal data is more tricky. Here I’m talking about internal processes which are absolutely no concern to the public, but only to the organization’s participants. And these participants are never going to accept that their internal matters are going to be on a public blockchain. However, the result of such a process might be written on the blockchain.

Let me give an example: A decision needs to be taken whether to accept a new member or issue new shares, etc. The current members or shareholders will then have an internal vote. The voting process itself is an internal matter, however the decision with the result of the vote is something which will be published publicly (on chain).

Considering the fact that state channels aren’t going to support multiple parties (for as far as I know) I wonder whether it could work if the company secretary would open a state channel and then use a virtual channel with every party allowed to vote on this matter. Then all votes on the virtual channels will be collected in the state channel and finally being written on chain if the particular decision requires so.

If that is an option it also makes me wonder whether a channel writes state to the blockchain only when it’s closed or if a channel can stay open and somehow write state to the blockchain whenever needed?

So far I’ve only been able to build solutions like this by using permissioned blockchain systems and it would be really great if I could use state channels in this way, because it would allow me to build solutions with just aeternity instead of a complex infrastructure combining public and permissioned blockchain.

2 Likes
11

What I get your use case is: you want a predefined set of people to make a decision and post it on-chain in a trustless manner. The following answer will be based on this undertstanding of the problem, I am wrong there, please ellaborate.

As I see it - there are two different problems: a distributed decision making and a trustless posting on-chain.

Postinng on-chain in an open an trustless manner

This is the easiest problem to tackle, so I start with it. In order for the block chain to be sure that this indeed is a correct decision that had been taken in a distributed and trustless manner, one must prove on-chain that this indeed is the case. Possibly the easiest solution will be a simple Smart Contract that checks that a provided message (containing the number of new printed shares or something) is indeed co-authenticated by all/enough of the stakeholders. Channels can not help you with this one, you just have to call the contract with the message that was produced by the decision making process.

Landing on a decision

This describes how to reach an agreement between N parties in a trustless manner. This is not a trivial problem and could be addressed in various ways: Virtual State Channels, private blockchain and etc. They all have their strong or weak proints. For example the VSC would possibly face the following drawbacks, mostly regarding information flow and race conditions. The secretary actor would be a centralized entity that would be responsible for coordination between all participants. It could drop or censor messages. It would have to resolve race conditions as in Alice votes in favor of X, this information should probably propagate to all participants. It could certainly be solved with Virtual State Channels but the devil is in the details.

Using (V)SCs, there would be some off-chain state and any participant would be able to force progress it, I am not sure how that would benefit the trustlessness. Probably this is the most important question to be answered: what do we want to force progress and thus ensuring the trustlessness of the process. For me personally this is where I draw the line: if there is no use of the forcing of progress, one probably can use a simpler approach.

The channel provides on-chain the smallest amount of information possible. It does not post anything unless participant(s) decide on posting. If you want to take information from the channel and post it on-chain, you can just co-authenticate a message using SC generic messages and later post it (via a contract call, possibly). This is a user level protocol that could be implemented on top of existing infrastructure (there are all the pieces you need, waiting to be used) but is not in the scope of the channel protocol itself. It is up to developers to decide how they want it :slight_smile:

2 Likes