Install Protocol
Last updated
Last updated
To illustrate the install protocol, first assume that the multisignature wallet owns 20 ETH and that the Free Balance application has recorded a balance of 10 ETH for both for Alice and Bob. Running the install protocol allows Alice and Bob to install an application where Alice and Bob both deposit 1 ETH to be disbursed based on the resolution logic of the application.
In this example, the application is Tic-Tac-Toe. You can see with the visual representation below that the funds available in the free balance decrease and the funds committed to the Tic-Tac-Toe application increase by the corresponding amount.
First we introduce a new type which we label InstallParams
.
Type: InstallParams
Field | Type | Description |
|
| The proposed sub-deposit into the application of the first party |
|
| The proposed sub-deposit into the application of the second party |
|
| TBD |
|
| The terms of agreement for this application |
|
| TBD |
|
| The definition of the interface of the application to be installed |
|
| The challenge period length for this application |
NOTE:
signingKeys
are deterministically generated based on the nonce of the application in relation to the entire channel lifecycle. Further detail still to be provided in these specifications in the future. See this issue for discussionNOTE: At the moment, this message requires that the hexidecimal value of
peer1.address
is strictly less than the value ofpeer2.address
to enforce deterministic ordering of thesigningKey
variable in new application installs. This can be improved in the future
Install
MessageField | Description |
|
|
| The address of the on-chain Alice-Bob multisignature wallet |
| An |
| The address of Alice |
| The address of Bob |
|
|
| Alice's signed commitment digest |
InstallAck
MessageField | Description |
|
|
| The address of the on-chain Alice-Bob multisignature wallet |
| An |
| The address of Alice |
| The address of Bob |
|
|
| Bob's signed commitment digest |
Commitment for Install
and InstallAck
:
Let c1
and c2
be the amounts that parties 1 and 2 wish to contribute towards the application respectively. Then, the commitment should:
Updates the state of the free balance application to one where the first party's balance is reduced by c_1
and party the second party's balance should be reduced by c_2
.
Makes a delegatecall to executeAppConditionalTransaction
with a limit of c_1 + c_2
as also included in the terms.
The following parameters are included in the commitment:
Parameter | Type | Description |
|
| Arbitrary value that the installed app's conditional transaction depends on inside the Nonce Registry |
|
| The computed |
The commitment can be visually represented like:
NOTE: Although not shown in the visualization, the order of transactions is important. The
multiSend
must encode the call toproxyCall
before the call toexecuteAppConditionalTransaction
.