I'm online messages

[cmichi]

This feature is intended to handle the case when validators go offline without malicious intent (i.e. without the intention of attacking the network). We don't want to slash them if there is no malicious intent.

Sending I'm online messages

• Each validator gossips an I'm online heartbeat every n blocks session.
• The heartbeat is a signed transaction, which was signed using the session key and includes the recent best block number of the local validators chain as well as the multiaddr (physical node address). It is sent as an Unsigned Transaction (no account nonce/signature/sender).
  • The multiaddr provides a secondary mechanism to look nodes up, since the DHT is flaky.

Interpreting I'm online messages

• There will be a points system for the token mechanics, which we can also use for tracking if validators are online.
  • A validator is considered online if a threshold number of points is reached.
  • If a validator doesn't hit the threshold it is considered offline.
  • By using a points threshold we determine if a validator is online by taking anything into account which a validator contributed to the protocol (and not just I'm online messages).
  • The threshold is probably going to be 1 (i.e. any points at all signify the authority is online).
• Create a new srml-im-online module which has a node_online hook.
• Introduce a validate_transaction trait in the srml-im-online module which interprets and validates the unsigned transaction.
• srml-im-online contains a map babe_session_key => Option<multiaddr>. Clear this map every time on_session_change() is called.
• Validators may only produce a single im-online transaction for each session in each chain. Further im-omline messages are ignored once a valid message has been received in the current session for that validator. No slash is made.

Future stuff with the points system

• Slash when a node is considered online according to the points system, but that node hasn't authored any blocks (or significantly less than expected) in a long time during which it should have authored blocks.
  • This "long time" is calculated by the likelihood that the node should have authored a block by now. If this threshold is below x then slash them. The further we get below this threshold the more we slash.
• If a validator is considered offline it is ignored as a validator, but not slashed. Kinda like a protection mechanism.

Open questions

• What of the above info is persisted on chain? Just the one map.
• How often is the heartbeat sent? Every block? Once per session.
• Where do we determine that a slash happens? In srml-im-online? Don't bother

[rphmeier]

Each validator gossips an I'm online heartbeat every n block

It should be triggered somehow, since it's not supposed to be arbitrary n, but rather all synchronized to the start of a BABE epoch ( == session)

How often is the heartbeat send? Every block?

See above.

When are token mechanics implemented? The interpretation of I'm online messages can't be finished until the points system is available.

Not entirely, but the logic of "do something if X says they're online" can be done, with "do something" being a trait parameter.

The exact percentage of how much we slash:
…in case of duplicate I'm online messages.
…in case of I'm online messages, but no blocks authored for a sufficiently long time

I would mark this as beyond the scope of the goal of getting information about those who say they're online into the runtime. The separation of architecture here will make things easier to audit.

Where do we determine that a slash happens? In srml-im-online?

Definitely not. It should be a trait associated type of im_online::Trait which in practice will be wired up to a Rewards system.

If more than one I'm online message arrives for a block they are slashed.

How do you check this, except to see if there are different signatures? And note that ed25519 signatures are deterministic, so with the same key, you always get the same signature for the same message.

[rphmeier]

I also don't know why the BABE module would be responsible for handling the incoming I'm Online messages if there is an srml-im-online module. We want this functionality to be reusable within Substrate. BABE should definitely have a hook where it can inform other modules that someone has authored a block.

[tomaka]

includes the recent best block number of the local validators chain as well as the multiaddr (physical node address)

It should also include the PeerId (aka. network key). We preferably don't want to just blindly dial a multiaddress.
And if we have the PeerId, we can also look into the DHT for a more recent list of multiaddresses for that PeerId in case the one on chain is unreachable.

[burdges]

We do need a mechanism for validators to be offline after session key revocation, but then rejoining requires key change and the incurred delay.

I doubt mere "I'm online" messages address any security concerns however, so can you explain what purpose this serves?

Al and I designed BABE variants that actually do prove your presence by proving exactly how many blocks you missed. We never pushed them and folks opted for the simpler design closer to ouroboros.

Instead, we wanted validators to be slashed for being offline in proportion to the number of validators who were offline simultaneously since the interesting attacks require more participants.

If more than one I'm online message arrives for a block they are slashed.

What does this achieve?

How do you check this, except to see if there are different signatures?

You likely compare what is signed and the signer, but not sure the point. And Ed25519 might not stick around in the session key.

[rphmeier]

You likely compare what is signed and the signer

Well, if you sign 2 payloads a and b with a deterministic algorithm, s(a) == s(b) when a == b. We'd need a way to differentiate between "I'm online in Session X" messages.

[burdges]

You must include the X regardless, so comparing the messages and signers works. Ed25519's determinism is mostly so that test vectors make sense. It gives you nothing else really.

[rphmeier]

@burdges I'm not sure that you follow the point, which is that you can't tell the difference between someone signing two "I'm online" messages and someone replaying the one that someone signed the first time.

[burdges]

I'm saying the only differences come from the message and the signer. A comparison a.signature == b.signature failing conveys zero information while a.msg == b.msg && a.signer == b.signer failing does. There are many valid signatures for a valid message and signer in particular, some of which a third party can produce from a valid signature.

[kianenigma]

@cmichi closed?

[cmichi]

Closed and follow-up integration ToDos are in #3223.