Developers Contest [CORRECTED]: Slashing Condition Design [3-23.08.2020.]

Governance contests Finished Contests
#1

Short description

TON Improvement Proposal (or TIP) for “slashing condition” specifications.

Type

Contest

Dates

Starts: 3 August, 2020 at 01:00 PM UTC, Ends: 23 August, 2020 at 24:00 PM UTC

Motivation

Slashing conditions for non-performing validator nodes were not fully implemented in TON. The fisherman code was developed, but no scripts yet were developed to use it.

Without balanced slashing, validators can ignore their obligations or perform with poor quality.

Free TON is aiming to implement slashing for stakes of non-performing validators in order to stimulate better validation quality and to guarantee network performance.

We would like to analyze the experience of existing PoS blockchains facing similar challenges and come up with an optimal solution based on inherited Free TON architecture

As such it should meet the following requirements:

  • Be based on analysis of experience and attacks.
  • The honest and performing validator should not be slashed (criteria calculation for the honesty and performance should be provided)
  • Use existing Free TON Consensus rules
  • Automate the slashing decision process on chain
  • Automation for the slashing conditions for masterchain as well as shardchain should be proposed
  • The description should be in clear technical language and sufficiently easy to understand
  • Need not to interfere with network performance
  • Slashing economics should be discussed
  • Slashing decision making process:
    • should be automated
    • must be based on objective criteria
    • should not depend on any validator’s desire or opportunity to vote

General requirements:

Participants should provide:

A technical description – a TON Improvement Proposal (or TIP) for design and implementation of the slashing condition mechanism.

Technical recommendations:

  1. Formal proofs are a plus
  2. Analysis of experiences and plans from existing PoS blockchains facing similar challenges (such as Cosmos, Polkadot, Near, Solana, Tezos, Cardano) is a plus

Notes:

  1. Slashing smart contract designs are not part of this contest and may not be provided
  2. Add a short abstract in the beginning, before the primary body text of the submission.
  3. Please try to stick to a font that is easy to read, preferably size 12. No Times New Roman please.
  4. Illustrations, including charts and/or other visual aids are always a plus.

Evaluation criteria and winning conditions:

Proposals will be judged strictly on the merit of their accuracy in addressing all requirements.

Only qualified proposals answering all the required criteria will be considered.

Rewards:

  • The 3 top winners will receive 100,000 TONs each.
  • The next 5 runners up will receive 5,000 TONs each.
  • All proposals will receive juror feedback.

The jury

  • Jury should be comprised of initial members and “Jury Selection Contest” winners from the community who have strong technical knowledge and experience.
  • Each Jury will vote by rating each submission on a scale of 0 to 10.
  • Jurors must provide short feedback on contestant submissions.

Jury rewards:

An amount equal to 5% of the sum total of all total tokens actually awarded to winners of this contest will be divided equally between all jurors who vote and provide feedback. Both voting and feedback are mandatory in order to collect this reward.

13 Likes
Developers Contest: Slashing Condition Design
#2

Great and important contest. Dates should be a little bit revised taking into the account dome time for Governance voting.

2 Likes
#3

I would interpret ‘on-chain’ term from above as of ‘Telegram Open Network Blockchain’ by N.Durov pp.100 4.1.4 Pure “on-chain” applications: distributed applications, or“dapps”, residing in the blockchain. Is that correct or another definition meant?

#4

I do not really understand what you mean by ‘interfere’ here. Would it be better to use ‘minimize’ instead (vs. Need to minimize network performance impact)? My argumentation is as simple as: every on-chain app interfere with a network performance.

2 Likes
#5

And finally - what is wrong with a fisherman apart from it is not completely implemented? Any conceptual misdirections here ‘’ pp.128 A3. Original supply, mining rewards and inflation. last paragraph?

1 Like
#6

Accepted by Governance voting https://freeton.org/proposal?proposalAddress=0:b6a379d5ffb4590abe3c72c36287b98f62ad57e09ee7d15c53c673055a2c49a3

Moved to Active contests!

2 Likes
#7

Tell me please, where can I find this code?

Подскажите, а где этот код найти?

#8

There is a checkload command in lite-client:

checkload[all|severe] [] 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

This is probably what @Mitja meant.

Cheers!

2 Likes
#9

Why there is no submission for this important contest yet? Just 3 days left… Come on community :wink:

#10

I want to submit my own version of slashing conditions for consideration, it will probably require some code change to calculate the average time for block to be signed by a validator, but such a scheme will help in the future to avoid slowing down the network by participants who cannot process blocks in a timely manner.
My submission is uploaded to the contest and if necessary can be added here as well.

#11

Are you sure you have posted it to the contest? Cannot find it here https://freeton.org/proposal?proposalAddress=0:b6a379d5ffb4590abe3c72c36287b98f62ad57e09ee7d15c53c673055a2c49a3

I think you also should publish it here on forum so that it can be discussed.

2 Likes
#12

Yes I’m sure what posted it in contest page, and even ask Roman about this as well, what I cannot see my proposal. Can we check it somehow?

1 Like
#13

Just sent our TON Improvement Proposal for “Slashing Condition” specifications, please check here for details: https://freeton.org/submission?proposalAddress=0:b6a379d5ffb4590abe3c72c36287b98f62ad57e09ee7d15c53c673055a2c49a3&submissionId=3

Feel free to contact: @zxcat, @andreypf

5 Likes
#14
6 Likes
#15
3 Likes
#16

Please check my submission to Slashing Conditions Contest.
Will be glad to see any comments and hope ideas from my work can improve FreeTon network and make it more stable and secure.

https://freeton.org/submission?proposalAddress=0:b6a379d5ffb4590abe3c72c36287b98f62ad57e09ee7d15c53c673055a2c49a3&submissionId=6

2 Likes
#17

My Slashing conditions TIP: https://freeton.org/submission?proposalAddress=0:b6a379d5ffb4590abe3c72c36287b98f62ad57e09ee7d15c53c673055a2c49a3&submissionId=7

I think this proposal will help make FreeTON more secure and decentralized.
Certain types of slashing may require additional discussions and cybersecurity audits.

4 Likes
#18

FreeTON: Slashing Condition Design

Developer Contest

23 AUGUST 2020

Abstract

These are 3 main issues with Validator in freeTON Blockchain

  1. Validator Signing Less Blocks and Longer Time - Making Network Slow
  2. Validator Nodes Down - Making Network less secure and vulnerable to attacks
  3. Double Signing of Block / Malicious Activities

We will discuss all these 3 problems and slashing conditions below in detail.

Validator Signing Less blocks than Others and Taking More Time in Signing Each Block

The Slashing conditions should be applied on validators who are not using good hardwares and network and connectivity in running the validator nodes. They may be using some cheap servers with poor connectivity which result in less blocks signing and more time taken in signing the blocks, thus making the overall network slower.

Although this is not a big threat to the network stability, as only ⅔ signatories are needed to pass a block transaction. But we should constantly remove bad validators and add new validators to keep the network fast and secure.

I am proposing a slashing condition which will be automated and will slash slow validators and also reward good validators.

Example:

Total Validators : 1000
Time Period : 15 days ( every slashing round, so that 1-2 days slow network of validators don’t make it a bad validator )

We can calculate the validator efficiency by calculating the power of each validator, where we will put greater weight on the number of blocks signed and some less weight on time taken to sign the block.

Validator Power = (Block Weight)(Block Signed) - (Time Weight)(Average time taken in singing the block over the period of 15 days)*(Total Blocks Signed)

For Example : Validator 1 Power = 2*(10000 blocks signed) - 1*(0.002 secs)*(10000 blocks signed)

We will rank the validators in the order validator power from 1 to 1000.

Note : One simple way is to slash the validators which came last and reward those who came in top, but I believe this type of blind slashing will punish even average validators.

Thus I am proposing a method of Mean and standard deviation. Only those validators who performed worse than the standard deviation should be punished, and if in a cycle no validator is permoring less than the standard deviation then none should be punished.

Mean will be = Total of all Validator Powers / Number of Validators

Deviation : (Mean Validator Power - Validator Power of Rank 1)

If Validator Power < ( Mean - Deviation ) - then validator will be slashed

In this case only those Validators whose power is less than the expected deviation, only they will be slashed.

Rewards for Good Validators : 2 Methods

  1. Divide slashed tokens to all validators above mean power equally.
    Like say 200 validators performed better than mean validation power, then all will get equal amounts of tokens, as all of them are better than average.

  2. Preferential Allotment of Rewards.
    This also applied to those validators who are above mean validation power, but it will reward more to the top validators and less to the other validators, thus creating competition to become more effective and earn more rewards, thus pushing the network towards better hardware and software and network.
    Like if 200 validators are above mean power, top 30 will get 50% of slashed tokens, while the rest 50% is distributed among the other 150.

I like Method 2 better, but I couldn’t come up with the arrangement of how much top validators should get more rewards than other, I believe this the whole community should decide.

Validator Nodes Down - Making Network less secure and vulnerable to attacks

Nodes are the backbone of the Network and Validators have the responsibility to keep these nodes running in good health and keep the network stable, and they are also getting token rewards for it.

If a few nodes get down at sometime then it’s not a problem but slashing condition is very important so that validators don’t take nodes for granted and make the network slow overtime.

Condition 1:

Slashing Cycle : 30 days
Validator Rewards per Month : Total Reward/12

If a node is down for more than 15 days the full reward for that month will be slashed.
If a node is slashed for 3 month continuously then they will get no rewards and they will be out of network. They will get no rewards.

Condition 2:

For 1 Day Network Down : 1% Slashing of Total Rewards.
Thus if a Node goes down 100 days in a year, they will get no rewards.
This 1% Slashing can be further divided into hours and minutes, so we can also slash if a node goes down for new minutes or hours.

For Ex :
24 hour = 1% slashing
1 hour = 1/24% slashing

Rewards for Good Valodators:

These slashed tokens can be divided equally among validators who had more than 99% or 99.5% uptime in that slashing cycle. Also we can provide these rewards for good validators according to power as discussed in the first part. That’s upto the community to decide.

Double Signing of Block / Malicious Activities

I believe fishermen technique mentioned in the TON Whitepaper is a good way to find fraudulent activities and double signing of Blocks.

Here the community can appoint fishermen and anyone with significant tokens and resources can join as a fishermen and try to catch double signing of blocks and other suspicious activities.

A slashing can be done anywhere between 5% to 100% depending on the frequency of these activities by the validators, and all reward goes to the fishermen.

I believe only fishermen who caught and reported the activity first should be rewarded, as it is the one who is gambling his tokens and resources to catch the unusual activity, thus the reward of fishermen should be high and it should not be shared with other validators, because validators are already getting rewards in above 2 cases.

2 Likes
#19

The core of my proposal to slashing problem is based on Magister Ludi’s M1 metric (uptime) and the extension of TVM. The proposed solution does not rely on any off-chain mechanisms, on-chain only with only two new necessary TVM instructions, so the implementation is totally possible entirely on smart-contracts logic.

Please check the proposed PDF for the details, the PDF’s SHA256 is 8cfc643bbf44fb3228723db80ad1293b06d9cbd651b5edc97df5b43fe4594a97.
The proposal and its attached PDF are accessible here: https://freeton.org/submission?proposalAddress=0:b6a379d5ffb4590abe3c72c36287b98f62ad57e09ee7d15c53c673055a2c49a3&submissionId=9

2 Likes
#20

Introduction

Actually I’m still studying ton.pdf and catchain.pdf documents and I’m trying to apply my knowledge to the results we get from four weeks of the Validation Contest. And I didn’t plan to take part in this Slashing Condition Design contest because I don’t feel myself so confident from the technical background viewpoint. So, please, excuse me for any possible technical misconceptions.
However, I was surprised to find that none of the published proposals solve what I believe is a huge problem that was identified during the passed Validators contest.

Abstract

The TON documentations states that the TON Blockchain is able to generate new blocks once every 4–5 seconds, as originally planned. Nevertheless we have all seen how this promise is not fulfilled even with less than 100 validators and a high load on the network. For example, these are excerpts from the statistics I collected during the validator contest:

4698 blocks was produced during 18 hours of 5-th cycle game1 week3. This gives us approximately ~13,8 seconds of average block time.
5890 blocks during 8-th cycle game1 week3 - ~11 seconds average block time
9515 blocks during 5-th cycle game2 week3 - ~6,6 seconds average block time
354 blocks during 6-th cycle game2 week3 - ~183 seconds average block time
3957 blocks during 3-th cycle game0 week4 - ~16,4 seconds average block time
2781 blocks during 4-th cycle game0 week4 - ~23,3 seconds average block time
4481 blocks during 5-th cycle game0 week4 - ~14,5 seconds average block time
7101 blocks during 6-th cycle game1 week4 - ~9,1 seconds average block time
6673 blocks during 7-th cycle game1 week4 - ~9,7 seconds average block time
4776 blocks during 3-th cycle game2 week4 - ~13,6 seconds average block time
1190 blocks during 5-th cycle game2 week4 - ~54,4 seconds average block time
2038 blocks during 6-th cycle game2 week4 - ~31,8 seconds average block time

The reason for so huge block time is that validation nodes with weak hardware do not sign blocks with expected speed so this leads to increase delay between signed blocks in the network.
The problem is not that the weak nodes are not signing the blocks at all. The problem is they are signing them slowly. In this case there is no reason to fine the node because following formal criteria it signed the block but from the practice perspective this could freeze the network as increasing block time from 0,2 sec to 5-10 minutes makes the blockchain non-functional even it is still produces the blocks.
Increasing the number of validation nodes makes the network more distributed so it is very good for the blockchain stability and it is expected. At the same time this increases the number of nodes required to sign every block and so increases network load and time necessary to sign the block. And when the number of such nodes, which do not manage to process the heavy load in time, will increase, the network stops working at all because of time out for block generation. So with an increase in the number of validators and an increase in network load, this problem will worsen.

Conclusion

The multi-blockchain structure of a catchain outlined in catchain.pdf leaves very little possibility for “cheating” in a consensus protocol built upon a catchain. At the same time, Validator contest shown that it is impossible to detect weak validation nodes using binary logic (made/didn’t make) for the actions like propose, approve, sign, vote.
All proposals that I’ve heard of are taking in to the account whether validator did or didn’t make some action like proposing, approving, signing, voting but they’re not measuring the speed of this actions which is a critical factor to network keep functional.

TON Improvement Proposal

Slashing should be verifiable by anyone interested so the only way to provide this is to keep slashing metrics in the blockchain itself.
My suggestion is that along with the block signature, each validator writes a signed timestamp to the block.
Accordingly, at the end of each cycle, it will be possible to trace these timestamps for each block and find those few percent of validators who sign the blocks the slowest. Thus, separate smart contracts will be able to analyze the collected data, find a bottleneck in network performance and fine validators accordingly.
At the same time, it is possible that malicious validators can save incorrect data as their timestamp. This way the delay will still be visible from the difference between the first and third consecutive timestamps (meaning the second is slow and malicious), but it will not be clear who exactly causes the delay for this particular block. From other side, the sequence of validators that sign blocks will be different for different blocks, so using statistical methods of analysis for large (> 10,000) number of blocks over a validation circle will allow us to identify validators around which delays are constantly occurring.

2 Likes