Blocknet trade fees: designing for good service node behaviour

A decentralized order book is like a public noticeboard: anyone can post anything to it and remove anything from it. So how to prevent people abusing the book or each other? Here is a quick stab at a solution.

Does your p2p network feel like this pile of clutter? Do people tear others’ notices down to make space for theirs? Time for some antispam and anti-DOS measures.

The Blocknet’s order system is decentralized: it supports order broadcast and order matching in a self-sovereign manner, maintaining order state across peers without a central entity determining state. Via Service Nodes, it also supplies messages to light clients that lack a blockchain, permitting them to construct SPV proofs of the truthfulness of the order data they receive.

It utilises a hashcash-style trade fee system to make it expensive to spam the order book or to DOS one’s counterparties in bulk. Secondly, it enlists Service Nodes to remove the necessity that traders pay a fee if they cancel their order before a counterparty consumes it, or if the counterparty triggers a rollback. This is important for maintaining feature-parity with centralized exchanges, and to encourage traders and bots to add liquidity to the market. After all, if it cost money to add an order to the book regardless of whether a trade results, then traders would only add liquidity when they were certain of the market direction and their entry price(s) over a long (-ish) period of time, as it would become expensive to act on new information from the market whenever it engendered cancelling existing orders.

To leverage Service Nodes to hold and not broadcast orders unless the right conditions result requires a careful balancing of incentives (though it benefits from the complexity-reducing factor that Service Nodes are policeable (p.32).

Some incentives to design for are:

1. Service Nodes should want to run as many blockchains as possible in order to support the order book and SPV nodes (i.e. competition is virtuous)
2. Service Nodes should not want to (or be able to) act maliciously against other Service Nodes (i.e. competition is vicious)
3. It should be more profitable to run a Service Node than to stake coins on the network, or else people would avoid the cost of running a Service Node and simply stake instead.

Alongside the ability to police Service Nodes, there are several sources of revenue with which to incentivise behaviour:

1. Network fees
2. Trade fees
3. XRouter queries (for use in SPV proofs)

Proposed design

1. Distribute trade fees to the network as network fees (see p. 31 of the whitepaper for details). Network fees are then awarded to the next winning staker.
2. Stakers thus probabilistically earn a fixed proportion of both (a) block rewards and (b) network fees.
3. Service Nodes would thus deterministically earn a fixed proportion (currently 70%) of the above reward, as per the current implementation.
4. Service Nodes’ eligibility to earn rewards depends upon their place in a revolving ranking system, enforced by network protocol. A Service Node’s rank depends on:
   (a) when last it received a reward (i.e. down to the bottom of the ranking after earning a reward),
   (b) the number of blockchains it hosts locally, weighted by order volume per blockchain,
   (c) its response latency, and
   (d) the number of other Service Nodes supporting each coin it supports (this is in order to incentivise supporting low volume coins. For example, if only you and one other Service Node supports xyzCoin, then your score will be very high for that coin, giving you an advantage over Service Nodes that only support Bitcoin and Ethereum).
5. Only one way to “legally” attack a Service Node is provided: for a trader to prove that a Service Node broadcast a trade fee illicitly (i.e. either before a counterparty accepts one’s order, or when the counterparty cancels). This may lead to a Service Node being blacklisted by any peers who validate the proof. No other “legal” methods of blacklisting exist; “illegal” attack vectors are hardened against.
6. A blacklist proof is a message broadcast to the network, including:
   (a) a trade fee txid including in OP_RETURN the addresses for the coins in the swap
   and either:
   (b) if a Service Node spends the fee as soon as it receives it: there being no corresponding atomic swap txs in the relevant blockchains after x blocks,
   or:
   (c) if the counterparty DOSes the trade but the Service Node still spends one’s trade fee: a refund txid and a delay of y blocks between the bail-in tx and the refund tx (indicating that the counterparty abandoned the trade; assumption: if you cancel, you’re DOSing the trade and thus you pay the trade fee).

Virtues of the design

1. (1) is easy to build
2. (2) and (3) are already built
3. (4b) incentivises Service Nodes to host all chains, or else if even one trade from an unsupported chain occurs in a block, they’d lose out. This encourages virtuous competition.
4. (5) and (6) do not enable Service Nodes to compete viciously.
5. The design greatly simplifies ensuring that (competitive) Service Nodes will always make at least a marginally greater profit than stakers, since all rewards are channelled through a single block-reward-and-network-fee proportional allocation (70/30, or 90/10, whichever is agreed upon).

Arlyn Culwick is a philosopher and technologist, a co-founder of the Blocknet, and an independent researcher in sign action. Flatus Vocis is a repository for spontaneous ideas and brain farts in decentralized p2p design scenarios. Posts are optimised for uberty over certainty, and are intended mainly to bootstrap musement. Chew before ingesting.