You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: cmd/fred/README.md
+25-6Lines changed: 25 additions & 6 deletions
Original file line number
Diff line number
Diff line change
@@ -24,20 +24,20 @@ Based on the hardware in existence, it represents the minimum amount of time to
24
24
## Auction protocol
25
25
Each auction has an Auction ID parameter.
26
26
27
-
1. Submit
27
+
1.**Submit**
28
28
* The submit stage should take roughly `(b*t)/n` time. `n` should be greater than 1.
29
29
* During the submit stage, users will submit timelock-encrypted orders with time parameter `t`.
30
-
2. Commit
30
+
2.**Commit**
31
31
* The commit stage marks the end of the "Submit" stage.
32
32
* During the commit stage, the exchange broadcasts a commitment to a set of encrypted orders.
33
33
* These encrypted orders include an unsolved puzzle, ciphertext, intended auction, and a hash.
34
-
3. Respond
34
+
3.**Respond**
35
35
* Users who receive the commitment before `b*t` send a signature on the commitment to the exchange.
36
36
* If the exchange receives unanimous signatures before `b*t`, the exchange broadcasts these signatures.
37
37
* If not all users signed off on the commitment, the entire auction is marked as invalid and must start over.
38
38
* Users should sign during this period if they're confident that the exchange could not have possibly solved a single one of the puzzles in the commitment.
39
39
* A single malicious user can halt the exchange during this step.
40
-
4. Decrypt
40
+
4.**Decrypt**
41
41
* This stage starts once the exchange has solved a puzzle, and decrypted an order in the set it committed to.
42
42
* This should happen after `b*t`.
43
43
* The exchange signs this data.
@@ -55,10 +55,10 @@ Each auction has an Auction ID parameter.
55
55
Then the exchange won't be able to sign an update to the data without revealing their private key.
56
56
In this case the auction would have to be restarted.
57
57
* In any case of an invalid auction, users don't need to pay attention to anything the exchange does that depends on the invalid auction.
58
-
5. Match
58
+
5.**Match**
59
59
* The exchange matches the orders, and signs the outcome of the matching.
60
60
* If the matching is incorrect, then it's incorrect and you can prove it.
61
-
6. Execute
61
+
6.**Execute**
62
62
* The exchange facilitates the trades through whatever settlement it feels like.
63
63
* Ideally this would be done through lightning atomic swaps, since proofs can be produced for an honest execution.
64
64
* In the case of lightning atomic swaps, blame can't be assigned to the user or the exchange if either party refuses to execute the trade.
@@ -83,3 +83,22 @@ Users could do a proof of work on their message once the auction has started, an
83
83
This would only be an issue if there is a large domain for proof of work.
84
84
This will normally be the case, since the message will include a signature, and the signature will be variable, depending on R.
85
85
This doesn't mean anyone can front-run, since the orders are still hidden and the exchange will be committing to taking a position if it commits to its own orders before a puzzle could have possibly been solved.
86
+
87
+
Stateless matching algorithms can be considered to be time independent.
88
+
89
+
### Stateful matching algorithms
90
+
91
+
We don't *have to* be stuck with only stateless matching algorithms.
92
+
We can use a combination of known, stateful algorithms that have a time priority requirement, and a stateless matching algorithm to have a persistent orderbook.
93
+
Every order in an auction must have the same time priority, so we can do the following steps to be compatible with a persistent orderbook:
94
+
95
+
1. Match in auction
96
+
* Nothing is different here than in the **Match** section of the protocol.
97
+
* Here, we must match according to a stateless matching algorithm.
98
+
2. Drop unfilled onto orderbook
99
+
* Here, we'll still be using a stateless matching algorithm, but only to settle "ties".
100
+
* Unfilled orders get put on the order queue with the highest time priority so far.
101
+
The sequence of auctions determines the time priority for orders on this orderbook.
102
+
In the case that multiple orders can be filled, but those orders have the same time priority, a stateless algorithm is used.
103
+
3. Match according to any matching algorithm
104
+
* Now, since we can settle ties with a stateless algorithm, we can use a stateful matching algorithm with the persistent orderbook.
0 commit comments