A virtual channel is a construct that allows 2 parties to transact directly with one another (similarly to a regular state channel), redistributing funds reserved from a set of ledger channels linking the two parties through a route of shared intermediaries.
We know of at least three models for architecting virtual channels:
Here, we have a discrete channel
J with Alice (
A), Bob (
B) and all intermediaries (
I) involved. The
J channel runs the consensus app. A 2-party Alice-Bob channel
X is funded directly from this channel using a simple allocation. We can visualise this as:
Here, the outer black circle and purple arrows denote on chain funding for the inner circles. The inner circles are channels with participants shown by the in-filled colour. Simple allocations are shown in black (opacity varies for emphasis). Guarantee allocations are shown in green. Note that this architecture is not currently supported by nitro (as of December 2022), since the guarantee structure can only be
reclaimedback into the ledger channels. To make delegated funding work, the money needs to move from the ledger channels into
Jand then into
Disadvantages of this model:
- There are 2 channels needed per virtual channel, which increases the gas costs to challenge / recover funds in the unhappy case.
- We need to revert to an older type of guarantee to support it.
Advantages of this model:
- the API of
Xis identical to a direct channel.
Xis adjudicated identically to a direct channel.
Xcould in fact become a direct channel, which makes security analysis simple. (This is not possible in the other architectures).
Here. there is a single channel
V where all parties are involved. After a certain turn number, the intermediaries are excluded from the execution of the channel and only Alice and Bob can update it. This period of execution can be thought of as a “sub channel”. Adjudicating
V involves validating the subchannel – if the subchannel is for example a lite channel, this may be as simple as checking signatures on vouchers.
- This is how things currently work in go-nitro / nitro-protocol.
VirtualPaymentAppis an example, where the unidirectionality of the channel has been exploited.
- This architecture results in the shortest possible challenge path, when measured in the number of channels which may need to be finalized on chain.
- Writing a new kind of
Vinvolves code duplication (which must be deployed on chain).
- It is not possible to take an application designed to be funded directly and easily convert it to being virtually funded
- We do not have an example of a bidirectional statically embedded app in the codebase at the current time.
- Adjudication is quite different to a direct (non-embedded) channel: it happens implicitly inside a pure function, so no state can be stored. This means each participant will only get one shot to challenge the channel. Security analysis therefore has to take into account how the channel is funded, even if the developer does not need to do so.
Here, there is an
Embedder channel (middleware) with all parties involved and once again an application channel
X, but the joint channel appearing in the static embedding architecture is replaced by
E: a generic embedder or middleware app that we (the statechannels core development team) provide.
E is adjudicated, it calls out to
X using the same API as full (e.g. a direct) channel. This is shown with a triple connector in the diagram.
- easy to write an app as if it is directly funded, and then upgrade it to virtually funded with no code changes
- the existing
virtualfundprotocol (happy path) and
reclaimmethod can remain unchanged.
- Adjudication is quite different to a direct (non-embedded) channel: it happens recursively inside a pure function, so no state can be stored. This means each participant will only get one shot to challenge the channel. Security analysis therefore has to take into account how the channel is funded, even if the developer does not need to do so.