Restore original TON Slashing

[creator]

TON Improvement Proposal for slashing condition specifications

by Peter Fedorov. August 2020.

Abstract

Slashing conditions are an integral part of almost all PoS blockchains. They are primarily intended to protect against problems like Nothing-at-Stake[6] that lead to forks and difficulty reaching consensus. In addition, slashing is often used to penalize validators who do not do their job well enough, and therefore harm the survivability of the network.
TON (and FreeTON) originally designed penalties for unscrupulous validators, this is mentioned in the White Paper[1] and other documents[2]. The slashing code is partially implemented, but it is still incomplete and does not work automatically.

This document will look at the slashing ideas embedded in the TON system, the tools currently implemented, ways to improve them to cover all violations, proposals to change the economy of slashing, and a brief description of slashing in other blockchains.

Punishment of validators according to the White Paper.

The TON documentation does not explicitly use the term slashing. Nevertheless, the possibility and necessity of fines and other punishments for unscrupulous validators has been repeatedly mentioned.

Cut out. See pdf for complete list of references

Summary on docs

Thus, penalties are provided for:

• Signing an invalid block candidate (penalty up to 100% of the stake + temporary or permanent exclusion).
• Participation in the fork of the network (penalty up to 100% of the stake).
• Signing an invalid shardchain block that was accepted by validators (up to 100% stake + temporary exclusion).
• Does not create blocks for long time (stake share penalty + temporary or permanent exclusion).
• Failure to provide a signed block from past (no punishment specified).
• Slow validators (decrease in block reward).
• Participation in the fork within the Catchain (penalty up to 100% of the stake).
• Suggestion of an incomplete collated block (no punishment specified).

Penalties for serious violations reach 100% of the stake. The second component of the penalty is temporary or permanent exclusion from the list of validators. This is done both to reduce the influence of an unscrupulous validator and to protect the validator from possible loss of the signature key. In addition, excluding a validator from the list of active ones protects the stake of its nominators (WP 2.6.3).
The amount received as a fine is supposed to be burned, thus reducing the amount of circulating Gram (TON Crystals), a small part of the fine can be transferred to the fisherman (WP A.3).

Implemented tools

There are currently two main slashing tools.

1. The smart contract elector-code.fc has a code that allows anyone to provide evidence of a violation committed by one of the validators (register a complaint). The second part of the code allows validators to vote to penalize the violating validator if the evidence is valid, that is, to support the complaint. If 2/3 of the validators vote, then a fine is imposed on the violator, part of which is received by the one who presented the proof.
2. The lite-client implements three commands that allow you to find non-performing validators, create proofs of their low-quality work, and also check these proofs for validity.

Let’s take a closer look at these tools.

Fisherman code algorithms

The fisherman code is in the elector-code.fc smart contract[4]. It allows you to create complaints, vote for complaints, and receive a list of active complaints, etc.

Registering a complaint

The message for registering a complaint must contain the payment for creating a complaint in the state, as well as a fee for registering it. The maximum reward depends on this fee. The message body consists of the following fields: Cut. Please check pdf

When the contract receives a message, the following happens:

1. The contract verifies that the complaint relates to an existing election that has not yet expired.
2. The fields reward_addr, created_at and paid are filled. In this case, part of the tokens transferred in the message goes to pay for the creation and storage of the complaint, the rest is written in paid.
3. A new complaint object is created.
4. It is checked whether the accused validator is in the current list of validators.
5. It is checked that the penalty is not more than the frozen stake of the validator.
6. It is verified that the fine is greater than the paid for the complaint.
7. An additional object is created - the status of the complaint.
8. It is verified that such a complaint does not exist.
9. The complaint is added to the current election.
10. The state of the contract is saved.
11. The amount paid for creating a complaint is reserved (raw_reserve).
12. A return message is sent.

Vote for Complaint

The following arguments are accepted as input:

• signature The 512-bit signature of the following data must match the public key of the idx validator (see below).
• sign_tag 32-bit, must be equal to 0x56744350.
• idx 16-bit index of the validator that votes for the penalty.
• elect_id 32-bit election identifier.
• chash 256-bit complaint identifier.

When the contract receives a message, the following happens:

1. The contract checks the value of sign_tag.
2. The weight and public key of the validator with the idx index are retrieved.
3. The correctness of the signature is checked.
4. It is checked that the election exists.
5. It is checked that the complaint exists.
6. It is checked that the complaint has not yet gained 2/3 of the total weight.
7. If the set of validators has changed, then the previous votes are discarded.
8. It is checked that the validator has not yet voted on the complaint.
9. The vote of the validator is added to the status of the complaint and the remaining weight is calculated.
10. If enough weight is gained, then the penalty is applied:
    1. It is checked that the punished validator has a frozen stake.
    2. The penalty is calculated equal to suggested_fine + (stake * suggested_fine_part / 2 ^ 32), but not more than the size of the stake.
    3. A penalty is deducted from the frozen stake of the validator.
    4. The reward is calculated equal to the lesser of:
       1. fine / 8.
       2. (paid per complaint) * 8.
    5. The reward is sent to the address specified when creating the complaint.
    6. The difference between the penalty and the reward is added to the total funds of the contract (grams), and also subtracted from the total_stake field, which stores the total stake of validators.
11. The state of the contract is saved.
12. A return message is sent.

Cut. Please check pdf for full list.

Get list of complaints list_complaints

Accepts a election ID as an input.
Returns a list of complaints unpacked including their hashes.

Proof of poor performance generated by lite-client

In lite-client[5], three commands are implemented to control the quality of validators, create and check evidence:

• checkloadall, checkloadsevere Checks whether all validators worked properly during specified time interval, and optionally saves proofs into .boc.
• loadproofcheck Checks a validator misbehavior proof previously created by checkload.

In the current implementation, the generated .boc file can be sent as evidence directly to the fisherman smart contract. Next, the validators extract the proof and check it using the loadproofcheck command. If the violation is confirmed, the validators vote to fine the culprit.

checkload* work algorithm:

1. The input receives a time interval, for which the work of validators should be checked, the validity of the interval is checked, for example, that it is not in the future.
2. The headers of the two blocks of the master chain are retrieved, corresponding to the endpoints of the interval.
3. Configuration parameters #28 (Catchain settings) and #34 (list of validators) are retrieved corresponding to each of the received blocks.
4. It is checked that the sets of validators are the same.
5. Statistics are retrieved on the total number of blocks created (by each validator separately in the masterchain and shardchains) at the moments corresponding to the extreme points of the interval.
6. For each validator, the number of created blocks in the masterchain and shardchains for the specified period of time is calculated (the difference between the total number of blocks at the extreme points of the interval is calculated).
   1. The previously obtained values ​​from the configuration parameter #28 are also checked so that the number of masterchain and shardchains validators does not change.
7. Using the Monte Carlo method, the share of blocks in shardchains is calculated for each validator.
8. The basis is taken that the number of blocks produced by the validators corresponds to the Poisson distribution (which tends to the Normal distribution with an increase in the expectation value). For each validator, based on the number of blocks it produces, the probabilities are calculated (separately for the masterchain and shardchains) with which the number of blocks it can produce relative to 90% of the expected number of blocks. In other words, how likely is it that the number of blocks produced by the validator matches the allocation.
   1. If the probability is less than 0.001%, it is considered a severe violation.
   2. If the probability is less than 0.1%, it is considered a moderate violation.
   3. In both cases, a proof file is created if it was requested when the command was invoked.
   4. The proof also specifies the penalties for using in fisherman code (validator_complaint):
      1. For an interval less than 1000 seconds, no penalty is applied and no evidence file is generated.
      2. The base penalty and base stake share are determined by the severity of the violation:
         1. Severe = GR$2500, 1/4 stake.
         2. Moderate = GR$1000, 1/16 of a stake.
      3. If the interval is >= 80000 seconds, a base penalty is applied.
      4. Otherwise, if the interval is >= 20000 seconds, the base penalty is applied divided by 4.
      5. Otherwise, the base penalty is applied divided by 16.
      6. It should be noted that the generated proof contains a zero address for receiving a reward (reward_addr) and also a zero value of the paid field, these values ​​will be filled by the smart contract upon receipt of a complaint.
9. Additionally, the results of the command are displayed on the screen.

The second command serves to check the evidence obtained from the outside.

loadproofcheck work algorithm:

1. A file with a proof comes in, an attempt is made to deserialize it.
2. The ValidatorLoadInfo objects corresponding to the endpoints of the interval are retrieved.
3. Similarly to the checkload* process, the lists of validators, the catchain config, the number of blocks created by each validator, etc. are retrieved. up to calculating the probabilities, the severity of the violation and the amount of fines.
4. The correspondence of the fine in the proof file and the calculated value is checked.
5. In case of inconsistencies, it is proposed to vote against the complaint, otherwise - for.

Thus, the code already has almost everything for slashing validators that do not fulfill their duties. It remains only to write scripts for monitoring violations and voting for fines, which will automate this.

Needed improvements

For automatic slashing to work, wemust:

1. Automatically find violations.
2. Automatically vote for violations found by other members.

To do this, it is proposed to write two scripts, each of which will do its job.

Violation monitoring script algorithm:

1. The script is called every two minutes.
2. The script calls checkloadsevere and checkloadall sequentially at intervals of 80000, 20000 and 1001 seconds.
   1. If the period overlaps with the change in the set of validators, the command will automatically end with an error, this will not be a problem for the script to work.
3. If no violations were found, the script ends.
4. If a violation is found, the most serious one found for each validator is selected. The severity is determined by the amount of the fine.
5. Next, for each of the violating validators, the list of previously saved violations is checked. In the list, the intersection of intervals is checked so as not to penalize for the same violation several times. At the same time, if the duration or severity of the violation has increased, the intersection of intervals is allowed, otherwise it will be impossible to fine for a more serious violation.
   1. It should be noted that the list is replenished not only with this script, but also with the script for voting for fines (see below).
6. If a suitable violation is found, a message is sent to the smart contract containing the proof of the violation.
7. If the submission is successful, the violation is saved in the processed list.

Algorithm of the script voting for fines:

1. The script is called every minute.
2. The script gets a list of active complaints list_complaints.
3. Each complaint is checked for its presence in the list of those already voted and in the list of those already excluded (dropout list).
4. If new complaints are found that are not in any list, then using the lite-client loadproofcheck command, the validity of the proof is checked.
5. Invalid complaints are added to the dropout list.
6. All valid complaints are divided by validators and checked against the list of saved violations. Complaints with overlapping time intervals, which have not increased in severity, are added to the dropout list.
7. If at this stage there are several new overlapping complaints with the same severity, then one of them must be selected. It is selected according to the start time of the interval (lesser time). If the time is the same, the time at which the complaint was created (lesser time) is used. If the time is the same, then according to the hash (smaller hash). Those who are screened out are placed in the appropriate list.
8. If new valid complaints are found, the script should vote for them.
9. In case of successful voting, the complaint is placed in the list of voted ones, as well as in the list of violations (so that the first script does not send it again).

Economy of current implementation

It should be noted that smaller (in terms of duration) disturbances accumulate before the onset of a longer one. That is, before a violation for 20000 seconds of downtime, the validator will receive 19-20 non-overlapping violations for 1001 seconds of downtime, and before a violation for 80000 seconds, it will receive 4 violations for 20000. At the same time, the amount of penalties:

• over 20000 is approximately equal to 16 offenses in 1001.
• over 80000 equals 4 offenses in 20000.

Thus, as soon as the violator crosses the threshold of the next violation, his total fine is approximately doubled.

Let’s simulate the amount of penalties for a validator that does not create blocks for a long time, in this case 80000 seconds. The penalty consists of two parts: the absolute value and the share of the stake.

1. Absolute values ​​of penalties (orange = moderate, red = severe):

As you can see, the total penalty after 80000 seconds of downtime will be 4375 GRAM (TON Crystal), but if a certain proportion of blocks are produced (violation does not fall into the category of serious ones) the penalty will be 10 times less.

2. Share of stake (orange = moderate, red = severe)

Explanation: The whole stake is 1.0 on the Y-axis, i.e. 50% = 0.5, 10% = 0.1.

As you can see, if you do not produce blocks at all, then after 80,000 seconds (this is approximately 22 hours and a quarter), the validator will have slightly more than 16% of the stake. If you produce an insufficient number of blocks (moderate violation), then about 64% will remain.

That is, in less than a day, the validator will lose almost the entire stake. In my opinion, stake penalties are very high and should be reduced by a factor of 100 or more.

Problems of the current implementation and how to solve them

Too big fines.

Solution: Reduce stake share penalties by 100 times.

There is no automatic generation of .boc to vote on a complaint

Solution: Add the required code to the loadproofcheck command. If the flag for generating a .boc file is specified, the command must create a file that can be sent directly to the smart contract.

Automation is performed by a separate script, if desired, it is easy to disable it.

Solution:

1. If most of the validators (2/3) are honest, then they will use the script, and it doesn’t matter if the others disable the script. Moreover, it is possible to additionally penalize validators who do not systematically vote for penalties. To do this, you can collect statistics on the number of votes for fines and the number of signatures of validators. Statistics should be collected only when there are not enough votes to punish a poorly performing validator. If there are enough votes, the lack of signatures is not a problem. Some validators nodes may simply not have time to vote before 2/3, for example, because of the different local server time.
2. The logic of the scripts can be transferred directly to the node. In this case, it will be much more difficult to disable them.

It is impossible to flexibly change the amount of penalties, as well as the time intervals for which penalties are calculated.

Solution: we should move the intervals and multipliers into the network configuration parameters so that the validators can change these values. For example get_config (X) will return:

{
  intervals: [1001, 20000, 80000],
  severities: {[
    {severity: 0.001, base_gram: 2500, base_part: 1/4, fines: [1/16, 1/4, 1]},
    {severity: 0.1, base_gram: 1000, base_part: 1/16, fines: [1/16, 1/4, 1]},
  ]},
}

Here, the fines correspond to the intervals.
That is, all parameters are included in the config, and they can be changed. Moreover, you can change the number of intervals and the severities of violations.

Despite the penalties, the stability of the network is not improved by the fact that any validator stops participating in the consensus.

Solution: it is necessary to modify the smart contract so that after the maximum penalty (for 80000 seconds of inactivity) the validator is excluded from the list of active validators or marked inactive. At the same time, he stops receiving fines, because no longer interferes with finding consensus. An excluded validator can apply for inclusion in the active list after a certain time.
The same logic is provided in WP 2.6.1

Only violations related to validator non-performing are taken into account.

Solution: we must also add evidence of other violations (see below).

The logic of the smart contract allows you to send overlapping and even coinciding violations, allowing you to penalize for one violation several times.

Solution: In automatic mode, when using the same scripts, this is not a problem for most honest validators. Only dishonest validators will send and vote overlapping complaints. Their weight will not reach 2/3.
Nevertheless, for greater stability, we should move the logic of working with intervals into a smart contract so that it does not allow creating overlapping complaints.

At the moment, the guilty validators are not suspend (WP. 2.7.4)

Solution: it is necessary to modify the smart contract to suspend validators. Upon reaching the maximum duration of 80000 seconds, the validator should be removed from the list. In this case, it should be impossible to re-enable it earlier than a certain time specified in the configuration parameter.
Other violations (double signing, participation in a fork, etc., see below) should also be brought to the immediate suspend of the validator.
It should be noted that the suspend of a validator should not change the list of validators that is used to check the quality of validators. It is necessary to leave the validator in the list, but mark it as inactive and prohibit any actions until the suspend expires.

Other violations

The main focus of this document was to design slashing conditions for non-performing validators. Nevertheless, slashing is most often used for other violations, in particular, double signing (more details in the appendix A). Moreover, the white paper and other documents describe several other violations for which unscrupulous validators are supposed to be fined. For some of them, you can easily add automatic processing.

Signing Invalid Block Candidate (WP 2.1.15)

Formal proof of block invalidation is not currently supported (WP 2.2.4), so this violation can be added after the implementation of formal proof.
Proposed 5% stake penalty and temporary suspend.

Participation in the fork of the network (WP 2.1.16)

Indicates the presence of validator signatures in more than one block that has the same height but different content. The formal proof of this violation is very simple, it is enough to provide the headers of two blocks that meet the criteria and the signatures of the accused validator.
A proposed 100% stake fine and permanent suspend.

Signing an invalid shardchain block (WP 2.1.17)

The formal proof of the violation can be a vertical corrective block paired with a corrected block. Validators whose signatures are present in the corrected (invalid) block should be punished. It should be borne in mind that only the initial block to be corrected is a violation. Blocks that are corrected due to the correction of the first block are considered to be created properly.
Proposed 25% stake penalty and temporary suspend.

Inability to provide own signed block from the past (WP 2.6.13)

Currently not supported in node implementation, formal proof is unknown. One of the proof options can be the absence of a validator’s response to a public block request. That is, the accusing party, which was unable to receive a block previously signed by the validator, forms a request publicly on chain. The request has a time interval during which the validator must provide a block, otherwise its stake will be slashed. If the validator provides a block, then the public request is closed. But here we should take into account possible scenarios of abuse, so further research is needed.
The proposed fine is 5% of the stake.

Fork to catchain (Catchain 2.7.3)

The Catchain document also mentions an additional violation at the consensus protocol layer (2.7 - 2.7.3). The violation is the same as participating in a fork of the network, the evidence is the same.
Proposed 5% stake penalty and temporary suspend.

Summary

Thus, scripts that work with fisherman code can be easily improved to support two additional types of proofs: fork proof and vertical block proof. Alternatively, all supported self-contained proofs can be verified in the smart contract.

The third type of proof is the lack of response to a request in the allotted time period, it should be worked out in more detail, the implementation in a smart contract will differ significantly.

It should also be noted that for these three types of evidence, it is not necessary for the validators to vote on the complaint in order to gain 2/3 of the weight. The contract can independently check their validity and fine the unscrupulous validator. But at the same time, we should add the processing of attempts to re-fine the culprit for the same violation.

TIP Requirements

I will separately list the requirements of the contest for this document.

Be based on analysis of experience and attacks

1. The mechanisms of slashing in different blockchains were discussed in detail (see a summary in Appendix A).
2. The methods proposed in the White Paper were discussed in detail.

The honest and performing validator should not be slashed (criteria calculation for the honesty and performance should be provided)

For non-performing violations, numerical methods of mathematical analysis and probability theory are used. This leaves a fairly large margin of error. For an honest validator, the probability of receiving an unreasonable fine for a moderate violation is 0.1%, of receiving an unreasonable penalty for a serious violation of 0.001%.
In other words, there is a chance of getting an unreasonable minimum penalty approximately every 1001 / (100/0.1) = 1001000 seconds or 3/4 years of continuous work. To obtain an unreasonable maximum fine, an average of 80,000 * (100 / 0.001) = 8 billion seconds, that is, more than 6,000 years, is needed.
It should also be noted that these parameters can be changed.

Use existing Free TON Consensus rules

The available tools are used to the fullest extent, as well as the ideas described in the original TON documents.

Automate the slashing decision process on chain

The proposed slashing option uses helper scripts as the first step in implementation. It is also proposed to transfer part of the logic to a smart contract, and the logic for finding violators can be added directly to the node.

Automation for the slashing conditions for masterchain as well as shardchain should be proposed

Proofs of the quality of validators are collected simultaneously for both the masterchain and shardchains. In addition, the violations listed in the Other violations section also affect both masterchain and shardchains.

The description should be in clear technical language and sufficiently easy to understand

I hope the language and style used is clear and easy to understand. If the reader has any questions, do not hesitate, ask, and I will be happy to answer and clarify.

Need not to interfere with network performance

This implementation does not in any way increase the load on the network in any significant way. Detection of violations can be performed on a local node without using the network. Submitting complaints and voting for them affects the network no more than normal token transfer transactions between wallets.

Slashing economics should be discussed

A small analysis of the existing penalties for the lack of block production is presented. I propose to reduce the fines. For other violations, we should also think more carefully about the economy. I propose to make all the parameters customizable, this will allow us to flexibly respond to the experience gained during the network operation.

Slashing decision making process:

• should be automated - it’s automated, no need to manual interaction.
• must be based on objective criteria - formal proofs and methods of mathematical analysis are used.
• should not depend on any validator’s desire or opportunity to vote - the proposed scripts and changes to the smart contract become part of the validator software. If there are more than 2/3 of honest validators with original software, the desire and possibility of separate dishonest validators does not matter. Moreover, some proofs, such as double signing, vertical block, are self-sufficient, and the corresponding penalties can be applied without voting by other validators.

Thus, all requirements are met.

Conclusion

The TON documentation (and therefore FreeTON) has a detailed description of the mechanisms for protecting the network from the actions of unscrupulous validators. These mechanisms have been partially implemented. To make the slashing mechanism fully operational, taking into account the experience of other blockchains, it is proposed to do the following:

• Implement scripts 1) monitoring violations and 2) voting for confirmed violations.
• Add to the smart contract of elections the ability to temporarily exclude validators from the list of active ones, including from all working groups.
• Revise downward stake penalty constants used in lite-client-generated proofs for non-performing validators.
• Add to lite-client the generation of .boc files for voting for complaints.
• The constants used to identify low-quality work, as well as to calculate the amount of penalties, should be transferred to the blockchain parameters so that validators can change them dynamically.
• Implement additional restrictions for overlapping complaints in the smart contract, so as not to punish for one violation several times. This only applies to complaints about non-performing.
• Implement automatic processing of double signing and vertical block proofs in a smart contract. This evidence is self-sufficient and does not require a vote on the complaint.
• Implement in the smart contract protection against re-sending double signing and vertical block complaints after the validator has already been punished.
• Make changes to the code of the node to automatically generate evidence double signing, double signing inside Catchain, creating a vertical block.
• For greater stability and determinism, transfer the logic of the proposed scripts directly to the node.
• Conduct research to create a formal proof of block invalidity (WP 2.1.15)
• Conduct more in-depth research into the evidence that the validator did not provide a signed block (WP 2.6.13). It is possible to implement the current proposed scheme.

The result will be a full-fledged slashing mechanism.

Appndix A. Implementation of slashing in other blockchains

Several PoS blockchains have been investigated, in which one way or another it is necessary to solve similar problems. In most blockchains, slashing is used to counter Nothing-at-Stake, often validators are also penalized for downtime.
Slashing was one of the first to appear in Tezos [7], where it raised a lot of questions, and was partially modified in subsequent blockchains. For example, many of the following blockchains introduce the concept of jail [8] or similar to exclude the offending validator from the list of active ones. It is worth noting Polkadot, in which the concept of slashing is most fully worked out [9]. In particular, some of the terms TON (“fishermen” and “nominators”) were borrowed from Polkadot (WP 2.9.8). Standing apart is the Cardano blockchain, which has abandoned slashing. Its developers claim that due to more advanced protocols they were able to solve many problems that were previously solved using slashing [10].

The economics and some of the possibilities of slashing in different blockchains are summarized in the following table.

Column descriptions:

• blockchain - the name of the blockchain.
• downtime - penalty for downtime, “-” means no penalty.
• doubleSign - penalty for double signing.
• jail - whether a misbehaving validator is blocked.
• burn - whether the penalty or part of it is burned.
• reward - whether the reporter is rewarded.

blockchain	downtime	doubleSign	jail	burn	reward
Cosmos	0.01%	5%	+	+	+
Polkadot	0.1% and up	1% and up	+	-	+
Near	-	5%-100%	+	?	?
Solana	?	+	?	+	+
Tezos	-	512TZ	-	+	+
Cardano	-	-	-	-	-

More blockchains:

blockchain	downtime	doubleSign
Harmony	0.01%	2% and up
ICON	6%	-
IRIS	0.5%	1% and up
Livepeer	1%	3%
Terra	0.01%	1%

---

Note:

This Proposal is submitted to the Free TON Slashing Condition Specification Contest

[creator]

Some parts were cut out because forum can’t accept such a big text, here you can get the full pdf

[creator]

Fixed the second image. Did no one read to this point?

[michaelshapkin]

Hi! I got 404 trying to open the pdf.

[michaelshapkin]

Correct link: https://gov.freeton.org/submission?proposalAddress=0:b6a379d5ffb4590abe3c72c36287b98f62ad57e09ee7d15c53c673055a2c49a3&submissionId=5

[creator]

Thank you. For some reason, the link has changed. The old one used to work.