Skip to content

Instantly share code, notes, and snippets.

@PokotyloMaryna

PokotyloMaryna/multi_channel_interaction.yml

Last active September 1, 2023 09:56
Show Gist options
  • Save PokotyloMaryna/911203cf7cdd6085752c6df356b6fc38 to your computer and use it in GitHub Desktop.
Save PokotyloMaryna/911203cf7cdd6085752c6df356b6fc38 to your computer and use it in GitHub Desktop.
Download ZIP
State channel test scenarios
Raw
multi_channel_interaction.yml
# Test 1. Verify Positive Multi-Channel Interaction and Settlement Between Alice and Bob
# Participants: Alice and Bob
# Conditions:
## Alice opens 1 channel with 1 participant;
## Consider Identical trade parameters between 2 participants;
## All settlements execute;
## All participants close their channel succesfully.
participants:
- name: Alice
address: "0xAliceAddress"
privkey: "a11ce00000000000000000000000000000000000000000000000000000000000"
rpc: "https://alice.com"
- name: Bob
address: "0xBobAddress"
privkey: "b0b0000000000000000000000000000000000000000000000000000000000000"
rpc: "https://bob.com"
actions:
t0:
- type: Connect
subsystem: core
participant: Alice
data:
endpoint: "wss://bob.com"
- type: Connect
subsystem: core
participant: Bob
data:
endpoint: "wss://Alice.com"
t1:
- type: OpenChannel
participants:
- Alice
- Bob
deposit: 5000
is_accepted: true
channel_id: alice_bob_1
t2:
- type: RecordTrade
participant: Alice
market: BTCUSDT
side: Buy
amount: 0.14
price: 29000.00
channel_id: alice_bob_1
- type: RecordTrade
participant: Alice
market: BTCUSDT
side: Sell
amount: 0.04
price: 33000.00
channel_id: alice_bob_1
- type: RecordTrade
participant: Alice
market: WETHUSDT
side: Buy
amount: 0.20
price: 1200.00
channel_id: alice_bob_1
- type: RecordTrade
participant: Alice
market: SHIBUSDT
side: Buy
amount: 20000
price: 0.0085
channel_id: alice_bob_1
t3:
- type: PriceUpdate
market: BTCUSDT
price: 31000.00
- type: PriceUpdate
market: ETHUSDT
price: 1001.002
- type: PriceUpdate
market: SHIBUSDT
price: 0.0090
- type: PriceUpdate
market: WETHUSDT
price: 1255.030
t4:
- type: MarginCall
is_accepted: true
channel_id: alice_bob_1
t5:
- type: RequestSettlement
participant: Alice
positions:
- WETHUSDT
- BTCUSDT
- SHIBUSDT
is_accepted: true
channel_id: alice_bob_1
t6:
- type: ExecuteSettlement
channel_id: alice_bob_1
t7:
- type: CloseChannel
channel_id: alice_bob_1
Raw
multi_channel_interaction_3p.yml
# Test 2. Verify Positive Multi-Channel Interaction and Settlement Between Alice, Bob and Charlie
# Participants: Alice, Bob, Charlie
# Conditions:
## Alice opens 2 channels with 2 participants;
## Consider Identical trade parameters between 2 participants;
## All settlements execute;
## All participants close their channel succesfully.
participants:
- name: Alice
address: "0xAliceAddress"
privkey: "a11ce00000000000000000000000000000000000000000000000000000000000"
rpc: "https://alice.com"
- name: Bob
address: "0xBobAddress"
privkey: "b0b0000000000000000000000000000000000000000000000000000000000000"
rpc: "https://bob.com"
- name: Charlie
address: "0xCharlieAddress"
privkey: "charlie0000000000000000000000000000000000000000000000000000000000000"
rpc: "https://charlie.com"
actions:
t0:
- type: Connect
subsystem: core
participant: Alice
data:
endpoint: "wss://bob.com"
- type: Connect
subsystem: core
participant: Alice
data:
endpoint: "wss://charlie.com"
- type: Connect
subsystem: core
participant: Bob
data:
endpoint: "wss://Alice.com"
- type: Connect
subsystem: core
participant: Charlie
data:
endpoint: "wss://Alice.com"
t1:
- type: OpenChannel
participants:
- Alice
- Bob
deposit: 5000
is_accepted: true
channel_id: alice_bob_1
- type: OpenChannel
subsystem: core
participants:
- Alice
- Charlie
deposit: 5000
is_accepted: true
channel_id: alice_charlie_2
t2:
- type: RecordTrade
participant: Alice
market: BTCUSDT
side: Buy
amount: 0.14
price: 29000.00
channel_id: alice_bob_1
- type: RecordTrade
participant: Alice
market: BTCUSDT
side: Buy
amount: 0.10
price: 29000.00
channel_id: alice_charlie_2
- type: RecordTrade
participant: Alice
market: BTCUSDT
side: Sell
amount: 0.04
price: 33000.00
channel_id: alice_bob_1
- type: RecordTrade
participant: Alice
market: WETHUSDT
side: Buy
amount: 0.20
price: 1200.00
channel_id: alice_bob_1
- type: RecordTrade
participant: Alice
market: WETHUSDT
side: Buy
amount: 0.30
price: 1250.020
channel_id: alice_charlie_2
- type: RecordTrade
participant: Alice
market: SHIBUSDT
side: Buy
amount: 20000
price: 0.0085
channel_id: alice_bob_1
- type: RecordTrade
participant: Alice
market: ETHUSDT
side: Buy
amount: 0.20
price: 1000.001
channel_id: alice_charlie_2
t3:
- type: PriceUpdate
market: BTCUSDT
price: 31000.00
- type: PriceUpdate
market: ETHUSDT
price: 1001.002
- type: PriceUpdate
market: SHIBUSDT
price: 0.0090
- type: PriceUpdate
market: WETHUSDT
price: 1255.030
t4:
- type: MarginCall
is_accepted: true
channel_id: alice_charlie_2
- type: MarginCall
is_accepted: true
channel_id: alice_bob_1
t5:
- type: RequestSettlement
participant: Charlie
positions:
- WETHUSDT
- BTCUSDT
- ETHUSDT
is_accepted: true
channel_id: alice_charlie_2
- type: RequestSettlement
participant: Alice
positions:
- WETHUSDT
- BTCUSDT
- SHIBUSDT
is_accepted: true
channel_id: alice_bob_1
t6:
- type: ExecuteSettlement
channel_id: alice_charlie_2
- type: ExecuteSettlement
channel_id: alice_bob_1
t7:
- type: CloseChannel
subsystem: core
channel_id: alice_charlie_2
- type: CloseChannel
subsystem: core
channel_id: alice_bob_1
Raw
settlement_not_finalized.yml
#Test 4. Verify Unhappy Common Case: Alice's Server Crash, Bob's Channel Challenge and Settlement is not finalized.
#Participants: Alice and Bob
#Condition:
##Alice's server crash;
##Alice's server is answering on margin_calls;
##Bob challenges Alice to retrieve money from the channel as collateral;
##Settlement is started, but never finalized.
participants:
- name: Alice
address: "0xAliceAddress"
privkey: "a11ce00000000000000000000000000000000000000000000000000000000000"
rpc: "https://alice.com"
- name: Bob
address: "0xBobAddress"
privkey: "b0b0000000000000000000000000000000000000000000000000000000000000"
rpc: "https://bob.com"
actions:
t0:
- type: Connect
subsystem: core
participant: Alice
data:
endpoint: "wss://bob.com"
- type: Connect
subsystem: core
participant: Bob
data:
endpoint: "wss://Alice.com"
t1:
- type: OpenChannel
subsystem: core
participants:
- Alice
- Bob
deposit: 5000
is_accepted: true
t2:
- type: RecordTrade
participant: Alice
market: BTCUSDT
side: Buy
amount: 0.14
price: 29000.00
- type: RecordTrade
participant: Alice
market: BTCUSDT
side: Buy
amount: 0.10
price: 29000.00
- type: RecordTrade
participant: Alice
market: BTCUSDT
side: Sell
amount: 0.04
price: 33000.00
- type: RecordTrade
participant: Alice
market: WETHUSDT
side: Buy
amount: 0.20
price: 1200.00
- type: RecordTrade
participant: Alice
market: WETHUSDT
side: Buy
amount: 0.30
price: 1250.00
- type: RecordTrade
participant: Alice
market: SHIBUSDT
side: Buy
amount: 20000
price: 0.0085
t3:
- type: PriceUpdate
market: WETHUSDT
price: 1250.00
t4:
- type: MarginCall
participant: Alice
is_accepted: true
t5:
- type: RequestSettlement
participant: Alice
positions:
- WETHUSDT
- BTCUSDT
- SHIBUSDT
is_accepted: true
t6:
- type: ExecuteSettlement
participant: Alice
is_finalized: false
t7:
- type: Challenge
participant: Bob
is_ignored: true
t8:
- type: CloseChannel
subsystem: core
participant: Bob #Bob closes the channel as Alice lost her connection
Raw
stop_responding.yml
# Test 3. Verify Unhappy Common Case: Alice's Server Crash and Bob's Channel Challenge
# Participants: Alice and Bob
# Conditions:
## Alice's server crash;
## Alice's server is not answering on margin_call;
## Bob challenges Alice to retrieve money from the channel as collateral
participants:
- name: Alice
address: "0xAliceAddress"
privkey: "a11ce00000000000000000000000000000000000000000000000000000000000"
rpc: "https://alice.com"
- name: Bob
address: "0xBobAddress"
privkey: "b0b0000000000000000000000000000000000000000000000000000000000000"
rpc: "https://bob.com"
actions:
t0:
- type: Connect
subsystem: core
participant: Alice
data:
endpoint: "wss://bob.com"
- type: Connect
subsystem: core
participant: Bob
data:
endpoint: "wss://Alice.com"
t1:
- type: OpenChannel
subsystem: core
participants:
- Alice
- Bob
deposit: 5000
is_accepted: true
t2:
- type: RecordTrade
participant: Alice
market: BTCUSDT
side: Buy
amount: 0.14
price: 29000.00
t3:
- type: PriceUpdate
market: BTCUSDT
price: 31000.00
t4:
- type: MarginCall
participant: Alice
is_accepted: false
t5:
- type: Challenge
participant: Bob
is_ignored: true
t6:
- type: TransferAllAssets
participant: Bob
t7:
- type: CloseChannel
subsystem: core
participant: Bob #Bob closes the channel as Alice lost her connection
@MaxMoskalenko
Copy link

  1. Add channel_id to this action
      - type: OpenChannel
        participants:
          - Alice
          - Bob
        deposit: 5000
        is_accepted: true
  1. I suggest another naming for channel ids: {intitator}_{follower}_{channel_nonce}, e.g. alice_bob_1 or bob_charlie_3
  2. About RecordTrades - it is not clear what Bob and Charlie recording to their systems. Pls specify (ideally it should be the same as Alice's, but also could be divergencies)
  3. I don't see any use of Alice-Charlie channel, so it makes this channel redundant
  4. No price update for SHIBUSDT - it is a good use case of empty price feed, but I guess this case is not part of this test
  5. Try to avoid such amounts for such markets:
      - type: RecordTrade
        participant: Alice
        market: ETHUSDT
        side: Buy
        amount: 20000
        price: 1000
        channel_id: channel_id_for_alice_1
  1. I'm not sure that we need participant field for the MarginCall, OpenChannel and CloseChannel, because it will always be Initiator of Channel

@PokotyloMaryna
Copy link
Author

@MaxMoskalenko

  1. Accept
  2. I think channel_id in RecordTrade type identifies that one participant sells, another one buys. For instance,
- type: RecordTrade
        participant: Alice
        market: SHIBUSDT
        side: Buy
        amount: 20000
        price: 0.0085
        channel_id: alice_bob_1

This snap means that Alice is buyer, Bob is seller.

  1. Accept
  2. Accept
  3. Accept
  4. Accept

@MaxMoskalenko
Copy link

  1. Ok, but we should keep in mind that participants could fool each other by recording different trades

@MaxMoskalenko
Copy link

Test 3:

  1. Change RequestDisputeResolution to Challenge. is_accepted - not the best name, but anyway we need some field that will describe how another party (Alice in this case) will answer to the call, I suggest is_ignored, where true means that Alice didn't appear, and false if she did
t5:
  - type: RequestDisputeResolution
    participant: Bob
    is_accepted: true
  1. There is no ExecuteSettlement after Challenge. At this case Bob could just withdraw all his assets (deposit + margin). You could use TransferAllAssets action to keep consistency with the SC

@philanton
Copy link

Also take a look into file format, for example action type should be snake cased and action params should be inside data field.
Here is an example.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment