Skip to main content

Attacks and penalties

In order to reduce the rate of misbehavior in the network penalization mechanisms should be implemented. For the tokenomics v1, the following penalization events must be in place.

Subscriber double-spending​

A Subscriber might be tempted to execute a double-spend attack to reuse the same credit multiple times or at least twice, that’s why it’s called the double-spending attack.

If such a situation is detected, the connection with that subscribing instance must be terminated. Note that a Subscriber as an on-chain entity can be represented by multiple instances, Clients that are using its subscription, and might not control their behavior. Therefore, we must evaluate any misbehavior and punish for it only if the double-spending was in fact caused by the Subscriber.

The type of penalization depends on the Subscriber staking feature (in addition to crediting the services):

  • Subscribers are not required to stake (tokenomics v1). It is impossible to penalize a Subscriber without penalizing all of its clients. This is due to the fact that Subscribers are only submitting the credit into the system. Hence, we can only reduce the credit and that would directly impact the Clients, rather than the Subscribers. We can only inform the Client that the Service is no longer credited and close the connection. Note that in tokenomics v1 we are assuming that the Subscriber-Client relation is trusted.
  • Subscribers are required to stake. It is possible to consume the stake of the Subscriber after proving their misbehavior on-chain. Therefore, in order to provide service continuity for the Clients, each proof of double-spending will consume the Subscriber’s stake to cover the unpaid service fee.

Client double-spending​

A Client might not adhere to the protocol and misbehave by trying to execute a double-spending attack. It would involve using the same consumption token multiple times with the same or different broker nodes.

Since Broker nodes are synchronizing, they can easily detect this attack. There are several courses of action for the Broker nodes.

  • Brokers must block the Client, but might not be able to generate proof of such misbehavior.
  • If Brokers can generate proof of such behavior and can escalate that to the Subscriber, the Subscriber could remove the authorization of that Client.

There is also a possibility that the Subscriber is guilty and provided the same consumption tokens to two clients. This should be provable and is covered in Subscriber double-spending.

Client request-flooding​

A Client might misbehave by sending multiple data delivery requests to multiple Brokers at the same time.

Due to synchronization within the Broker network, Broker nodes can detect this attack and generate proof of such behavior. Similar to Client double-spending, Broker nodes can:

  • first and foremost block that Client;
  • generate the proof of misconduct, since the same consumption tokens will be used multiple times. This proof can be relayed to the Subscriber in order to remove the authorization to use the Service for that particular Client.

Broker submitting invalid proofs​

A Broker can submit an invalid PoD on-chain. It can also mean that a number of Observers can falsely attest to it. This is a very unwanted event, which must be severely penalized. A significant portion of the attacking Broker’s credit must be slashed.

Let’s assume 100% of his credit is slashed and put into a reward pool alongside the credit of Observers, who attested to the faulty proof. Note that only the credit of the submitting Broker is slashed, whereas, the delivery of data could have been performed by several Broker entities. Then:

  1. If the proof includes only a single Broker entity, then the submitter of the challenge receives 100% of the reward pool and is eligible to receive all of the network fee that was reserved for the Broker and all falsely attesting Observers.
  2. If the proof includes more than a single Broker entity, then the submitter of the challenge receives 100% of the pool reward and is eligible to receive the network fee, but only the share that was reserved for the submitting Broker and all falsely attesting Observers.

In both cases, the correct Proof of Delivery has to be submitted to the chain by the challenger. Moreover, in both cases, the Subscriber pays the fees according to the declared usage in the correct proof and the Publisher receives the rightful reward.

Observer Invalid Proof Attestation​

If an Observer attests to an invalid PoD, 100% of its credit should be slashed. Similarly to the previous case, the correct proof has to be submitted on-chain by the challenger.