zk-Matchbook
Trivia: Matchbook FX (1999-2002) was the world's first ECN for forex markets on the internet.
There are 3 design goals for zk-Matchbook:
- 1.Relayer must NOT learn the original value in a locked account.
- 2.Relayer should NOT have the custody of tokens.
- 3.Relayer can NOT spend a transaction maliciously.
For the first property to hold true, it is very important that the client runs a prover locally. This way the client can prove some spending condition on an amount that is separate from the total amount in the account.
There are two types of transactions that are accepted as an input to the matching engine,
LendTx
and OrderTx
. Both of these txs are generated in the browser of the client and hides the amount in the account with an inequality check. For detailed VM stack, please refer to:Every
LendTx
locked at the relayer changes the state of TLV
and TPS
by locking some wBTC in a LendState
. PoolShare
calculated for every transaction is pushed to the stack as a commitment and is not revealed to the user. where
TPS
is the sum of all the PoolShare
values calculated for every LendTx
. These values are appended to the txlog
of the transaction to keep an on-chain record for auditability purposes. Similarly the withdrawal values are calculated using the same
PoolShare
commitment from the txlog
.To make sure the client is synced with the most recent state of
TLV
and TPS
, the client send the lendTx along with TLV and TPS commitments. The relayer then checks whether commitment received is the current state and locks the transaction accordingly.Last modified 2yr ago