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
typeDerived fields
These fields are not included in InstallVirtualAppParams
but are computed from existing information known to a user.
{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
rightETHVirtualAppAgreement
A commitment to call ETHVirtualAppAgreement::delegateTarget
terms
:
terms
: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
M2
M3
M4
M5
Summary
Last updated