I noticed some interesting behavior while running a local test net on my machine. I booted up a network between the default Alice and Bob accounts that are used in all the tutorials, and they connected fine, with both terminals showing that they had found a single other peer. I use a custom chainspec in this network.

Next, I re-entered the same command to start Bob in another terminal, and, although I needed to pass another tmp directory for the chain data, it started fine, and connected. I was surprised, because it seems like the consensus process should not accept a second incarnation of Bob into the aura and grandpa processes.

Is this standard behavior? How do votes work in the consensus process under these conditions? Can it be prevented, if undesired via a governance pallet? I guess if the two incarnations of Bob each proposed a different block it would be a problem, or if their votes counted twice in the consensus process it would be bad too.

How are such issues prevented at the protocol level?

  • Thanks @AurevoirXavier - this is interesting. But, AFAICT, it's not documented that multiple identities can "do stuff" by default. Nor is it explained what you can do or not do. Commented Jan 26, 2023 at 19:19
  • What is a dev to do? Commented Jan 26, 2023 at 19:20

1 Answer 1


There is no limitation on the node side. You could start multiple Bob nodes at the same time.

But we have do_report_equivocation on the runtime to prevent/punish this misbehaviour.

You could check the code doc for more detail and to learn how it works.



Please also check pallet-offences.

In short, any other nodes(validators) could report the malefactor then the system will disable it and slash some tokens from its account.

For AURA, it's pretty centralized. There isn't a reporting mechanism.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.