Architecture Design Idea of Atomic Swap Predicate


#1

Overview

This document describes an architecture design of simple atomic swap predicate.

Background

@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.

We got an idea of this deprecation logic from atomic swap predicate suggested by @karl here.

Also credits to @ben-chain, who shared his insight on a potential attack here before, it helped us to elaborate on the operator’s withholding attack, explained later in the Attack Scenario 1 section.

As for use cases, I believe this predicate could nest a Collateral Predicate to build Lending Plapps which was proposed by @syuhei176 before.

Architecture

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

Deprecation Logic

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,

  1. 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 (corresponding StateUpdate).

  • [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 A|B (corresponding StateUpdate).

    **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.

  • [A|B->B]: [A|B->A]

  • [B|A->A]: [B|A->B]

  1. To startExit counterparty’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.

  2. 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.

  3. 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 Scenarios

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.

  1. Op’s exit happens before the confirmation: Alice can simply cancel her swap choosing not to send a confirmation signature to Bob

  2. 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.


#2

Thanks for article! This is really interesting, but I’d like to clarify.

  • First of all, about definition. Is I right about this? (See below.)

    Definition
    Conditional state is called the state in which party A transfers its coins to counterpart B, provided that party B transfers its coins to its counterpart A. Let’s mark it A | B.

  • 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.

    Let’s do it step-by-step:
    1. There are to conditional states A | B and B | A.
    2. Conditional states B | A (the state which “promised” that B give its coins to A) was checked by Alice.
    3. She sent a confirmation signature to Bob and waiting his confirmation signature.
    4. Next you write, that

    Alice is always guaranteed an option to exit B|A in case Bob deprecates A|B without sending a confirmation sig B to Alice.

    Seems, that she need an option to exit A | B, but not B | A And a bad scenario, when Bob deprecates B | A instead A | B, … Besides, B | A situation is a good for her and this is impossible without B signature. Or am I misunderstanding something?

Besides, I’ll try to put a honest swap procedure in these terms, please, correct it if I’m wrong. Suppose that both are honest.

Block 1.
Alice has A-Coins.
Bob has B-Coins.
They want to submit state update.

Block 2.
Alice “create” a conditional state A | B. A-Coins still in Alice’s ownership.
Bob “create” a conditional state B | A. B-Coins still in Bob’s ownership.
They check that everything ok.

Block 3.
Alice sent a confirmation signature to Bob. A-Coins still in Alice’s ownership
Bob sent a confirmation signature to Alice. B-Coins still in Bob’s ownership.
And here we need two inclusion proofs, yes? Please explain this to me… How do you send this inclusion proofs? Is it possibles to use SNARKs here? Or it isn’t necessary?

Block 4.
! After all checking is done !
Alice has B-Coins.
Bob has A-Coins.

I’m sorry if I ask stupid questions.
Thank you in advance!