Slashing Policy Proposal

Pursuant to FP-2, the Forta Foundation has worked to create a formal slashing policy and is now seeking community feedback prior to presenting the policy to the Forta Governance Council for approval. A formal slashing policy will put in place increasingly permissionless crypto economic mechanisms that incentivize the good behavior of scanners, bots and other possible future agents in the network.

Staking is live for scanner nodes and soon for bots, so the next step is to develop the processes and mechanisms for the slashing of said stake in cases that the staking subject is acting against the Forta Network, either for malicious or operational reasons.

Slashing reasons and their spirit.

For Scan Nodes operators, SLA score is the main mechanism used to determine bot assignment and rewards. However, this policy will not slash nodes for low SLA scores, since having low scores would mean the scanner is getting less work and less or no FORT rewards, and factoring the costs of running a node it would mean low SLA scanner nodes run at a loss and should therefore naturally remove themselves from the network over time.

However, there may be factors not contemplated by SLA that make a scanner node underperform, harming the health of the bot(s) it is assigned. In this case, when this type of underperformance is discovered and reported, the relevant node should get slashed for a percentage of its stake. This type of slashing proposal may therefore be a source of improvement for SLA parameters.

Additionally, a scanner node could engage in censoring, forging of alerts, malicious activity and misreporting in order to cheat the network and earn rewards in an unfair way. If proved, this behavior would merit the slashing of most of the stake (90%).

Factors that could merit near total slashing:

  • Not providing the minimum technical requirements specified in the Forta docs, in a way not yet contemplated in SLA calculation.
  • Censoring, forging or tampering with bots and alerts.
  • Faking performance metrics.
  • Not providing performance metrics.
  • Any other proven malicious activity.

For Detection Bots, developers could:

  • Submit bots with the intention of clogging the network (spam).
  • Create bots that fail in a way that affects the scanner node, affecting the Scanner’s SLA.
  • Demand an excessive amount of resources from the Scanner Node.
  • Attack the Scanners, the Forta Network or another party.
  • Bots whose alert misrepresent the purpose stated on their description or that fail to alert subscribers in the way they advertise.
  • Any other proven malicious activity.

The subject of excessive resource consumption by bots is trickier due to the open and flexible nature of Forta’s bots, so perhaps in the future a system could be devised where bots could pay for resources according to their needs. For slashing, the arbiters and slashing committee would consider the cases where the demand is detrimental to Scanner Nodes and other bots.

In both cases, adequate documentation of the processes will be published to help proposers, and communication channels will be open.

Slashing Proposal Process

Roles

  • Proposer:

Individuals or bots that detect evidence of a slashable offense and propose the slashing of a staking subject, assigning initial blame and reason for the proposal.

To have a public and permissionless proposal process, and since proposing a slashing freezes the stake of the suspect staking subject (bot or scanner), proposing cannot be free.

The Proposer would need to present a FORT deposit for each proposal. This deposit is at risk of being sent to the treasury if the report is deemed in bad faith or too poorly constructed.

  • Slashing Arbiter:

Technical reviewer of the slashing proposals. She needs to verify that:

  1. The proposal is well constructed and in good faith. If the proposal has merit, the deposit will be returned to the proposer. If not, the deposit will be sent to the slashing treasury.
  2. Investigate the evidence. Correct the blame and the reason if needed, presenting more evidence (for example the report blames a bot for not firing an alert, but it was the Scanner node’s fault).
  3. Mark the proposal as ready for slashing.

At this point, due to the openness of the reports the verification of the evidence requires some manual processes and the Arbiters will be a committee named by the Governance Council, with appropriate expertise and without FORT incentives, with the committee further automating and decentralizing into the future.

  • Slasher:

Decides to either:

  1. Execute the proposal, with the following effects:

  2. Slashing the subject’s stake, with the tokens being split between the slashing treasury and the proposer.

  3. Sending the withheld rewards back to the rewards pool.

  4. Revert the slashing proposal, unfreeze the stake and assign the rewards being withheld.

Initially, we propose this role is granted to:

  • The arbiter committee for partial slashes due to operational reasons.

  • The Governance Council for major slashing proposals.

  • Staking admin

Sets the parameters for staking and slashing.

  • Slash reasons and penalty amounts.
  • Amount of FORT deposit for proposals.
  • % of the slashing amount going to the Proposer.
  • Treasury address.

This role is initially assigned to the Council’s multisig, which will enact the results of Snapshot voting.

Initial Parameters

  • Slash reasons:
    • Operational complaint. Penalty: 15% of Min Stake
    • Malicious or fraudulent. Penalty: 90% of Stake
  • 50% of slashed stake for slash Proposer.
  • 1k FORT deposit for each slash proposal.
  • Treasury address: [TBD]

Evidence Format

Each Slashing Proposal must have an IPFS hosted file associated with the following format.

{

“title”: string,

“description”: string,

“subjectId”: string,

“subjectType”: number,

“penaltyId”: string,

“checksum”: string

}

  • Title: title of the slash proposal, max 100 characters long.
  • Description: 5000 characters max describing the case, markdown encouraged. Example:
    • The logs presented (evidence_1) prove that the scanner is censoring my bot’s alerts.
  • subjectId: uint256 id of the subject to slash (scanner, bot)
  • subjectType: 0 for scanner, 1 for bot.
  • penaltyId: bytes32 hash representing the penalty applied.
  • Checksum: keccak 256 hash of all the other (key,value) pairs of the file.

Each case can have several JSON files with evidence (logs, screenshots) hosted in IPFS. Both Proposer and Arbiter must present evidence when creating or modifying the proposal.

Evidence JSON:

{

“fileURI”: string,

“fileHash”: “”,

“fileTypeExtension”: “string”,

“name”: string,

“description”: string,

“checksum”: string

}

  • fileURI: IPFS URI, example: “/ipfs/QmWQV5ZFFhEJiW8Lm7ay2zLxC2XS4wx1b2W7FfdrLMyQQc”
  • fileHash: IPFS file hash, example: “QmWQV5ZFFhEJiW8Lm7ay2zLxC2XS4wx1b2W7FfdrLMyQQc”
  • fileTypeExtension:”txt”, “pdf”, “png” or “jpg”
  • fileName: name of the file
  • description: description of what the evidence portrays. 100 char max.
  • checksum: keccak 256 hash of all the other (key,value) pairs of the file.

Future work

With the maturing of the Forta Network and the learnings of initial slashing processes, we expect 2 non-exclusive ways of further decentralizing the triaging, review and executing stages of the proposals.

  1. Automatically verifiable slash reasons. Expected when the code and functionality of Scanner Nodes and Bots ossifies more. In this scenario, automated reporting will be less risky, and the community could spin “proposal review” bots (with the corresponding stake and incentives) that should slash when a quorum is reached.
  2. Incentivized slash proposal reviewers. This could mean the creation of a reviewer DAO or integration with arbitration systems like Kleros or Aragon Court.
7 Likes

I think this should be more specific, because we are talking about 90% slashing here and there are a lot of things written on that page.

2 Likes

90% is waaay too much, 10% more than makes the point. There are circumstances where a user error could cause slashing.

2 Likes

I think we can join a process to check the machine configuration. If people’s cup or memory is insufficient, we should cancel the reward they deserve

Agree, that should go into the Operational Complaints (15% of min stake).

90% should be for something malicious, like “there is proof these scanners censored alerts from this bot, which lead to a hack not being detected”.

1 Like

What is the purpose of the 8gb memory and 4 CPUs constraint?
For sure it’s no guarantee for performance, so I really fail to see why it’s important.
As an example, I’ve effectively configured a VM with 4vCPU and 8GB RAM. On this VM I’ve successfully deployed 4 instance of forta. All checkes have passed.

Question you should ask is how much of the 8GB RAM are dedicated to one forta instance, or how much of the 4CPUs are exclusively used by forta, or even how powerful are the CPUs anyway… Not an easy task to code.

Second, why make node providers invest in hardware that is not used at the moment.

3 Likes

Suggest further refinement of the rules
For the slash ratio suggested according to the severity according to the different proportion of the penalty.
In the early stage, as long as it is not very obvious intentional evil, do not punish too heavily, otherwise it is easy to cause significant property damage to the node because of potential agreement problems or misuse problems.

1 Like

I would like to know more about what is ineffective work and for how long?

Maybe, a better way whould be to look at overall system load.
As an example, for RAM only, I would check percent of RAM used every few minutes. If, say for the last few hours, I get an average of more than 80% this would mean that the system is too loaded and could underperform. So you cand decide to offer 0 rewards until the problem is fixed.
This can be done also for CPU, and it’s a much better indication for performance than simply locking at the number of cores.

1 Like

I’m absolutely agreed with Cristian! It’s much more precisely to monitor percentage of RAM and CPU used for Forta, not just monitoring the amount of cores used :face_with_monocle:

We let each bot have 1 GB memory limit and have been keeping that as a standard. 16 GB memory is safe enough for a node with 25 bots to continue without disruption, because one node has to be very unlucky to receive too many memory intensive bots. On the other hand, reducing the available memory on one machine increases the chances of downtime. The bots can take down a node more easily and the scan node software has more intensive memory consumption when scanning some chains (e.g. Polygon).