Slashing

[dabasov]

Slashing is a special mechanism for incentivizing committee to not break the rules and operate properly. Important to mention that slashing is a general framework and is not connected directly with financial penalizing or any balance manipulations. We can use different types of penalizing: reduce reputation of peers, ban for an hour or simply replace with candidate. Specific implementation is left for «permissioned service» and now I will propose common mechanism.
If fraud proof is not valid sender, sometimes is called «fisher», will lose it’s fee part.

Tx

type = Type.SLASHING ## slashing request 
to = adversarial ## adversarial address
nonce = nonce ## tx sequence
value = 0 ## amount 
fee = fee ## regular fee to prevent tx DDOSing
signature = sign ## signature
data = fraud_proof ## main difference of slashing is fraud proof in data field, fp is a different protobuf structure, serialized to byte array

Lets examine different equivocations:

• Multiproposing
  Leader proposes different blocks to different peers. Peer who received bad block and voted for it will eventually receive QC with good block from the same proposer on the same height. Fraud proof can be made with this data. (How can we prove that QC is made for adversarial proposal? By design, network will reject any proposal issued by anybody else)
  FP

type = Multiproposing
Messages [
proposal_1
QC
]

• Multivoting
  It can be hard to detect this type of fraud since only next proposer receives votes and only one of all multivotes has ability to form QC. It is useful to store votes for at least one round, and when all QC are published analyze received votes for blocks on same height.
  FP

type = Multivoting
Messages [
vote
QC
]

• Not extending PREF block
  When analyzing forks one can find breaking «extending PREF block fork» rule. Although this type of fraud is pretty resourceful to detect (fisher have to analyze each Vote for each Proposal in fork) it is necessary to detect such frauds to provide protocol safety.
  FP

type = PREF
Messages [
QC_[i-1, i] #QCs not on PREF path on height i
Vote # vote on height j > i
header[i..j] #ordered header chain  header_i<>header(QC_i)
]

• Bad block proposing (???)
  Leader proposes block on wrong height (is it worth it?), or with unreachable state, etc (what we can find out with basic validations). Probably this should be moved to lower level (network probably and controlled via banscores) since information about fraud is contained in message that we validate and do not require any additional info
  FP

type = BadBlock
Messages [
proposal
]