double-signing protection

[Hyung-bharvest]

1. problem definition

• validators often mistakenly run duplicated validators to cause double-signing incident
• this proposed feature is to reduce the risk of mistaken double-signing incident
• when we think of such serious impact on double-signing incident, it is very reasonable to have multiple protection algorithm built in gaiad

2. new feature

• "gaiad start" has default setting to not participate on consensus, aka "fullnode as default"
• after starting gaiad, user enter command "gaiad activate-validation --from {key} --pubkey {valconspub}" with the signature from the {key}
• when gaiad receive this command, gaiad will look up recent(predifined block heights) consensus result and search for any consensus votes by given validator operator of the {key} AND also by given {valconspub}
• if there exists any vote from given validator operator or {valconspub}, gaiad will reject(or reconfirm) the activate-validation request and stays in fullnode
• if there exists no vote from given {key}, gaiad will transform this node from fullnode to validator which only use the private key paired with given {valconspub}
• when priv_validator_key changes while node is running as validator, the given {valconspub} and the new pubkey of priv_validator_key does not match therefore the node will not sign any consensus vote.
• all default setting can be customized by config.toml

3. B-Harvest wants to tackle this when we confirm enough support from community.

[tac0turtle]

I believe this can be considered a duplicate of #2237 (comment). We have discussed this on a few calls, just not gotten around to working on it.

[Hyung-bharvest]

I believe this can be considered a duplicate of #2237 (comment). We have discussed this on a few calls, just not gotten around to working on it.

We will review #2237 and provide updated spec so that it can include the "mode" abstraction! Thank you for connecting this!

[alexanderbez]

Seems reasonable. One question I have surrounds the following:

when gaiad receive this command, gaiad will look up recent(predifined block heights) consensus result and search for any consensus votes by given validator operator of the {key} AND also by given {valconspub}

Will it only need to look past "unbonding period" # of blocks?

[Hyung-bharvest]

@alexanderbez no. Practically it will be definitely much less than that. I am imagining like 50 blocks or less.

The main purpose of this feature is to double check that another node is "currently" validating with same valoper or valconspub on the chain.

I think maximum look up height might be around several hundred blocks because this usecase does not need more.

[alexanderbez]

I think you still have to be careful here though. The node could be offline > 50 blocks.

[Hyung-bharvest]

That's true. Maybe we want to

1. check whole # of unbonding period(this might take very long time tho..)
2. tell users that the most recent consensus vote height and time by given key
3. then re-ask user that he/she really wants to start validating(type "yes I really do") if vote exist in the period

How do you think?

[tac0turtle]

I think to start just have a node not be started with privval.json, the feature of switching is a bit harder and would have to have more in-depth thought and research, but would be easier solved when we have different modes for validating and full nodes

[Hyung-bharvest]

Keep in mind that looking up recent votes is only possible if the node is synced well.(and it is one of the prime objective of this feature) Therefore, if we want to add the prevention method to check recent votes, the procedure should be from non validating > validating while it is running.

What we can differentiate fullnode/validator mode is that

1. fullnode mode always stays in fullnode(not validating)
2. validator mode starts from inactive submode(syncing but not validating) and it can transform from inactive to active(validating) submode when requested as written procedure above.

[Hyung-bharvest]

below is our new spec of double-signing protection which also includes "mode" concept.

1. problem definition

• validators often mistakenly run duplicated validators to cause double-signing incident
• this proposed feature is to reduce the risk of mistaken double-signing incident
• when we think of such serious impact on double-signing incident, it is very reasonable to have multiple protection algorithm built in gaiad

2. tendermint mode v0.1

• the state machine has two modes to start : fullnode & validator
  • fullnode mode : fullnode mode does not have any capability to participate on consensus
  • validator mode : this mode is exactly same as existing state machine behavior. sync without voting on consensus, and participate consensus when fully synced.
• broad direction of implementation
  • state machine cmd flag "mode" : fullnode(default), validator
  • fullnode : in state machine, do not load "priv_validator_key.json"(consider non-existence)
  • validator : working same as existing state machine

3. double signing protection(only for validator mode)

• general objective
  • check recent consensus votes to prevent double-signing
  • allow users to ignore this checking feature
• broad direction of implementation
  • consensus vote check
    1. when a validator is transformed from syncing status to fully synced status, the state machine check recent N blocks to find out whether there exists consensus votes using the validator's consensus key
    2. if there exists votes from the validator's consensus key, exit state machine program
  • parameter setting(when starting state machine)
    1. --vote-check-height : how many blocks state machine looks back to check votes
    2. state machine ignore checking procedure when vote-check-height == 0

Implementation detail will follow up soon next week!

[melekes]

Per #5147 (comment), #5147 will not work without fast sync / state sync.

[tessr]

I think this Issue is now effectively a duplicate of the one that's tracking the "Tendermint Modes" work, so I'm going to close it. But please re-open it if I misunderstood!