[Protocol3] Create circuit permutations with fewer fee payments

[Brechtpd]

Our current circuits do A LOT of token transfers, which uses a lot of constraints. We may want to create circuit permutations that do not do this many. If needed, Orders/Rings can contain an identifier in which circuit permutation they can be used.

For example, for an Exchange that does everything itself (wallet + ring-matcher + operator) we only need to pay a fee from the order to a single wallet. All payments to the ring-matcher and payment from the ring-matcher to the operator can be removed, greatly increasing the number of constraints used by the circuits (and thus greatly increasing the achievable throughput).

[Brechtpd]

Let's explore some options.

All fee payments (current circuit)

orderA.tokenS -> orderB.tokenB
orderB.tokenS -> orderA.tokenB
orderA.tokenS (margin) -> ring-matcher
orderA.tokenF -> orderA.wallet
orderB.tokenF -> orderB.wallet
orderA.tokenF -> feeRecipient
orderB.tokenF -> feeRecipient
ring-matcher -> operator

As you can see, lots of different accounts (tree depth of accounts is 20, so expensive to update). Much cheaper to do a lot of payments to/from a single account (tree depth of balances is only 8).

A

The absolute minimum amount of token transfers we can do (with a fee payment):

orderA.tokenS -> orderB.tokenB
orderB.tokenS -> orderA.tokenB
orderA.tokenS (margin) -> operator

This is very limited.

• No way for users to choose the feeToken
• A fee is only paid by a single user
• The way we currently enforce the burn rate not possible (because the margin is used) though solutions for this could found (e.g. the fee is a percentage of amountS).

B

orderA.tokenS -> orderB.tokenB
orderB.tokenS -> orderA.tokenB
orderA.tokenS (margin) -> operator
orderA.tokenF -> operator
orderB.tokenF -> operator

Still very efficient and flexible:

• No wallet that can be different for every order
• No ring-matcher that can be different for every ring
• Current fee system is still completely usable

[dong77]

@Brechtpd Given that we simplified fee payment to ring-matcher in #197 , should we close this issue?

[Brechtpd]

@dong77 Yes, let's close this one. I think we should still think about how to reduce payments somehow if possible, but not in the way described in this issue.