Install Virtual App Protocol
This is the Install Virtual App Protocol.
Roles
Three users run the protocol. They are designated as initiating
, responding
, and intermediary
. The first two parties are the users wishing to interact together in a virtual app, who do not necessarily have a ledger channel between them. It is required that initiating
and intermediary
have a ledger channel together, and that responding
and intermediary
have a ledger channel together.
The InstallVirtualAppParams
type
InstallVirtualAppParams
typeField | type | description |
|
| xpub of |
|
| xpub of |
|
| xpub of |
|
| |
|
| |
|
| Encoded initial app state |
|
|
|
|
|
|
|
| Not implemented in machine yet |
Derived fields
These fields are not included in InstallVirtualAppParams
but are computed from existing information known to a user.
Field | type | description |
|
| State deposit holder for the channel between |
|
| State deposit holder for the channel between |
|
| See below |
{initiating,responding,intermediary}
, together with the target app sequence number, are used to derive the app-specific signing keys. signingKeys[0]
is the intermediary signing key, while signingKeys[1:2]
are the signing keys used by initiating
and responding
, sorted lexicographically by public key.
Commitments
leftETHVirtualAppAgreement
A commitment to call ETHVirtualAppAgreement::delegateTarget
with an Agreement
argument with the following fields
Field | type | description |
|
| From network context |
|
| See below |
|
|
|
|
| Hash of appIdentity of target virtual app |
|
|
|
|
|
|
rightETHVirtualAppAgreement
A commitment to call ETHVirtualAppAgreement::delegateTarget
Field | type | description |
|
| From network context |
|
| See below |
|
|
|
|
| Hash of appIdentity of target virtual app |
|
|
|
|
|
|
terms
:
terms
:Field | type | description |
|
|
|
|
|
|
|
|
|
limit
is explicitly ignored by the contract, while assetType, token == 0, 0
means ETH.
targetVirtualAppSetState
The protocol produces a commitment to call virtualAppSetState
with the initial state. Note that intermediary
produces a "type 2" signature while the others produce a "type 1" signature. This ensures that the intermediary's signature can be reused for calling virtualAppSetState
with other app state hash values, i.e., that the intermediary does not need to be part of the update-virtual-app protocol.
The signatures s5
and s7
are the signatures of initiating
and responding
respectively on d1
while the signature s6
is the signature of intermediary
on d2
.
Messages
M1
Field | Type | Description |
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
|
|
|
| The S1 signature |
|
| The S5 signature |
M2
Field | Description |
|
|
|
|
|
|
|
|
|
|
|
|
| The S5 signature (forwarded). |
| The S3 signature |
M3
Field | Description |
|
|
|
|
|
|
|
|
|
|
| The S4 signature. |
| The S7 signature. |
M4
Field | Description |
|
|
|
|
|
|
|
|
|
|
| The S6 signature. |
M5
Field | Description |
|
|
|
|
|
|
|
|
|
|
| The S6 signature. |
| The S2 signature. |
| The S7 signature. |
Summary
Signature | Commitment | Signed By |
s1 | leftETHVirtualAppAgreement | A |
s2 | leftETHVirtualAppAgreement | I |
s3 | rightETHVirtualAppAgreement | I |
s4 | rightETHVirtualAppAgreement | B |
s5 | targetVirtualAppSetState | A |
s6 | targetVirtualAppSetState | I |
s7 | targetVirtualAppSetState | B |
Message | Signatures |
m1 | s1, s5 |
m2 | s5, s3 |
m3 | s4, s7 |
m4 | s6 |
m5 | s6, s2, s7 |
Last updated