This document describes an architecture design of simple atomic swap predicate.
@syuhei176, @tkmct and I attempted to design a deprecation logic that allows two different coin owners to swap their coins in a safe way, supposing that both participants are online throughout the process until their exits.
Swap between Alice and Bob
In the end, you want these following conditions.
[A->B]: Range A, which was previously owned by Alice, has to be transferred to Bob
[B->A]: Range B, which was previously owned by Bob, has to be transferred to Alice
Definition: X|Y symbolizes a conditional state having two scenarios of state transitions later depending on the situations, either:
both sides of the swap were included, so Y is the new owner; or
only one side of the swap was included (the swap was unsuccessful), so X is still the owner.
First, both coin A and B exit as a conditional state A|B and B|A, which will be deprecated later either to confirm or cancel the swap process.
To assure that both of the swap participants can exchange their ranges as they agreed in a mutually beneficial way,
- The following conditional state cannot be deprecated by their counterparties unless
[A|B->B]: Bob has a confirmation signature from Alice, which claims that Alice agrees that the ownership of range A is transferred Bob, and an inclusion proof of
[B|A->A]: Alice has a confirmation signature from Bob, which claims that Bob agrees that the ownership of range B is transferred to Alice, and an inclusion proof of
**Each party sends a confirmation signature to the counterparty after checking that the conditional state of the counter party’s coin is included in a block.
Without them, the swap process will terminate and ownership of the coin will be simply transferred to the original owners.
startExitcounterparty’s coin, swap participants need an inclusion proof of its conditional state.
Say Alice checked B|A was included, so she sent a confirmation sig A to Bob. While waiting for Bob’s confirmation signature, Alice is always guaranteed an option to exit B|A in case Bob deprecates A|B without sending a confirmation sig B to Alice.
If both of the conditional states’ exits have been pending for fixed n days of ‘dispute period’, then the ownership of the coin will be simply transferred back to the original owner.
If B deprecates A|B and exits, while A has not been done with B|A’s deprecation, then extra dispute period will be executed on Layer 1 and B|A will automatically be deprecated as A’s coin.
Attack Scenario 1
Suppose Alice is an honest user and the operator is maliciously colluding with her counterparty Bob. Alice and Bob own their coins at block 1 and submits a state update to a conditional state A|B and B|A in block 2. Then the operator attempts to exit coin B, which was supposed to be transferred to Alice, in block 3.
Alice can protect her assets in either of the following ways.
Op’s exit happens before the confirmation: Alice can simply cancel her swap choosing not to send a confirmation signature to Bob
Op’s exit happens after the confirmation: Alcie can challenge the operator’s fraudulent exit using the inclusion proof of coin B’s conditional state B|A.
Attack Scenario 2
Again, suppose Alice is an honest user here, and the operator is maliciously colluding with her counterparty Bob.
The operator includes both Alice and Bob’s coins’ statUpdate to the conditional state A|B and B|A in block 1. Both Alice and Bob send confirmation signatures to each other, but the operator withholds Bob’s confirmation signature in block 2. Therefore, only Bob can deprecate Alice’s conditional state and exit with her confirmation signature.
In this case, Alice can exit coin A with the following protocol;
Applying rule 4, exited B|A will be put on a trial with an additional dispute period on Layer 1. Coin A’s conditional state will be automatically deprecated if there is an inclusion proof of A|B in block 1 and Bob’s confirmation signature in block 2.