chore: prevent spam and make watch tower more scalable

[anxolin]

Background

Watch Tower will keep track of conditional orders.

Conditional orders will activate in some conditions, and generate discrete orders in the order book.

Depending on the conditional order implementation, some smart orders will require more checks than others. As orders have now a way to signal to watch tower their next check should only happen at a certain time TRY_AT_EPOCH or at specific block TRY_ON_BLOCK.

However, in the worst case, orders can always signal to check on next block: TRY_NEXT_BLOCK

If the order activates very seldom, and makes watch towers to check on every block, there's no incentives for watch towers to index those orders.

This ISSUE is about researching ways to improve this situation.

Here is a set of assumptions that will help to introduce the problem and potential solutions.

Assumptions

💬 Assumption: Not all orders are equally valuable for CoW Protocol / CoW Swap

TWAPs is a feature in CoW Swap, end users use it, therefore CoW Protocol care about these orders being indexed.

On the other side, there are other orders, that might be TESTS by some devs and might be less relevant. Maybe is just a PoC and they even don't have funds to back them up.

💬 Assumption: What is valuable order for one, is not for another

If you are a protocol, like YEARN, Maker, you might decide to create my own custom and super specific Conditional Order.

Your protocol might be the only one interested in the trade, as its the only one using it. Obviously, the protocol has an incentive to make sure this orders are being indexed.

💬 Assumption Not all orders are equally efficient to index

CoW SDK has a Conditional Order implementation being used by Watch Tower that makes it very efficient to index TWAP orders (we don't need to check every block, we know precisely the moments where we should check - see tests for details)

On the other side of the spectrum:

• i.e We could have a smart order, that only activates once every 3 months, and makes watch tower to check on every block (~15s). This means Watch tower will need to check 0.5M times before it can create an order.

💬 Assumption: Devs can make the SAME ORDER more or less efficient to verify

Developers can have a choice to make.

In the example of the TWAP, we could implement it by checking on every block, its definitely easier implementation. If we just don't care about the costs of indexing, we will sure do that! However, in as mentioned above, TWAP really calculates the time in which each part should be created so only in those prices moments its created (see tests for details)

Assumption: Stop indexing

It is possible that an order is not valid after a given date. For example in TWAP you signal Watch Tower you don't need to keep track of the order any more after they placed the last part of the TWAP order (See https://github.com/cowprotocol/cow-sdk/blob/main/src/composable/orderTypes/Twap.spec.ts#L554)

If Dev don't instruct this to Watch Tower, orders will be watched forever.

If you are a dev who don't care about others spending resources indexing your order, then you might skip the part of signaling the order should not be indexed any more: DONT_TRY_AGAIN

Proposals

Up until Step 6 should be fairly easy to do, and give us already quite some scalability and flexibility.

🐮 Step 1: Make Watch Tower open-source

• Composable CoW is open source: https://github.com/cowprotocol/composable-cow
• So it is Watch Tower: https://github.com/cowprotocol/watch-tower
• So it SDK is open source: https://github.com/cowprotocol/cow-sdk/blob/main/src/composable/index.ts

🐮 Step 2: Make Watch Tower easy to run

• Docker: https://github.com/cowprotocol/watch-tower#docker
• Dappnode: https://github.com/cowprotocol/watch-tower#dappnode (👏 @mfw78)

🐮 Step 3: Allow Smart Contracts to signal when to index next

Smart contracts will be able to signal the Watch Tower the followin: TRY_NEXT_BLOCK, TRY_ON_BLOCK, TRY_AT_EPOCH, DONT_TRY_AGAIN

@mfw78 could you add here the docs when ready?

• Allow to signal next poll to Watch Tower from Smart Contract

🐮 Step 4: Allow to enhance Smart Contract indexing logic to make Watch Tower indexing more efficient

Anyone can make the indexing more efficient by implementing their own poll logic in the SDK.

Even if the Smart Contract is not the most efficient, we can fix by having additional polling logic in the watch tower, where we can signal: TRY_NEXT_BLOCK, TRY_ON_BLOCK, TRY_AT_EPOCH, DONT_TRY_AGAIN . See:
https://github.com/cowprotocol/cow-sdk/blob/main/src/composable/orderTypes/Twap.ts

We can even for example, signal to watch tower that polling our order once every 5min is enough, this will make your order 20X more efficient to index (as you only check one out of every 20 blocks.

• Allow to signal next poll to Watch Tower from SDK

🐮 Step 5: Whitelisted orders

Assuming not orders are equally valuable for everyone we could whitelist the ones we really care about and not index the other ones.

Alternatively, we could index the other ones, but with restrictions (TBD what restrictions)

• Add whitelist of handlers/owners

🐮 Step 6: Restrictions on orders (low hanging)

If an order is not in our whitelist, they will have "restrictions".

One potential first step (low hanging), is to never index these orders more often than once every 5min.

If someone makes a useful order, they can always contact to add it in the whitelist or they can also run Watch Tower themselves whitelisting their own order

• Index non-whitelisted orders with restrictions

🐮 Step 7: Credit system

We could offer a Credit Sytem with a free-tier for indexing orders with restrictions.

We could create a credit system based on the gas consumed in the polling (or a number of RPC calls, which might be simpler if the gas on a read call is harder to get).

If you surpus your credit for the time bucket, the watch tower will schedule your next polling for after the time backend ends.

The accounting of credits could be per owner, or handler.

• Accounting system per owner/handler
• Put orders on hold if they don't have more credits

🐮 Step 8: Payed polling

If a handler or owner is interested in being indexed but they don't want to run Watch Tower, there could be a way to tip the indexers. We could keep it simple, just by adding a price in DAI to buy credits.

• Top up your credits