configuration tendermint_mode=Full has unexpected behavior may lead to double sign

[0x4r45h]

Description:

Namada V1.0.0

I need clarification on the tendermint_mode configuration in config.toml. Specifically, the behavior when setting it to "Full".

Steps to Reproduce:

Start a node in Full mode (tendermint_mode = "Full").
Observe the "This node is not validator" message at startup.
If the node has the correct consensus keys in the cometbft directory and enough voting power (VP), it starts signing blocks regardless of the mode.

Observed Behavior:

When set to Validator, if the validator keys are missing from wallet.toml, the node crashes with an error.
When set to Full, the node runs without issue but may start signing if it has consensus keys and enough VP.

Expected Behavior:

Clear and predictable behavior depending on the mode to prevent potential double signing or misconfiguration.

Questions:

1.Are there any additional side effects of this configuration?
2. What this mode should be in multi-signer setups?
For instance, should full nodes connected to a cosigner cluster be set to "Validator" or "Full"?
Setting to "Validator" requires keys in wallet.toml (which could be any validator key, not the actual one used in the multi-signer), while "Full" works without them. Are there any risks or hidden side effects in doing this?

Expected Impact:

Clarifying this behavior is critical for avoiding misconfigurations, especially in high-risk setups like multi-signing where improper modes could lead to double signing or node crashes.
I suggest removing this configuration entirely, if possible, similar to how other CometBFT-based chains operate. To my knowledge, these chains do not use this setting—the node simply begins signing blocks as long as it has sufficient voting power (VP).

[brentstone]

@tzemanovic @Fraccaman @sug0

[tzemanovic]

Hi, tendermint_mode config doesn't affect operation of CometBFT - the log message is slightly misleading.

1.Are there any additional side effects of this configuration?

As you noted, the "Validator" mode requires existence of validator wallet. Additionally, it allows validators to set their accepted_gas_tokens via validator_local_config.toml (I don't think this feature is documented anywhere yet)

2. What this mode should be in multi-signer setups?
   For instance, should full nodes connected to a cosigner cluster be set to "Validator" or "Full"?
   Setting to "Validator" requires keys in wallet.toml (which could be any validator key, not the actual one used in the multi-signer), while "Full" works without them. Are there any risks or hidden side effects in doing this?

Using "Full" mode is fine in such setups.

[0x4r45h]

Hi @tzemanovic,

Thanks for the clarification. I believe that sooner or later, someone will end up double-signing due to a misinterpretation of the validator_mode flag. We've already seen discussions in the Discord where some validators are designing disaster recovery plans and mistakenly think that by setting validator_mode = full, their backup node will not sign blocks.

I believe we should add a warning in the docs about this issue.
And again, In my opinion, this flag should be removed entirely in future releases.

[tzemanovic]

hi @0x4r45h, I think we'll fix the validator_mode = full to switch out validator keys, if any (and backup original), because there's some logic tied to this settings and it won't be a breaking change. This way, the config should work as expected.