Can ProposerAddress be trusted?

[faustbrian]

I'm reading through the specifications of ABCI methods and data structures in order to perform an action for the validator of a block. Based on what I read so far the idea would be that my application keeps track of the ProposerAddress that can be retrieved in BeginBlock. Then in EndBlock I could do whatever I need to do to that validator account, for example hand out a block reward.

My question is caused by the the specific wording of ProposerAddress which is Address of the **original** proposer of the block., see https://docs.tendermint.com/master/spec/core/data_structures.html#header. The original part is what makes me wonder if I can trust this value and use it for the purpose of triggering actions based on it or if it could change between BeginBlock, EndBlock and Commit. I assume the answer to this is no because a proposal/block can be discarded so in that case I would never even receive the EndBlock call.

[creachadair]

Hi @faustbrian. The way it is implemented right now, consensus verifies that the ProposerAddress is a legitimate validator for that height, but there is not currently any proof it was the validator who proposed the form of the block being committed. This mainly matters if the height goes to multiple rounds, so that the eventual proposer may be different from the first proposer in the height.

As implemented, the ProposerAddress is set to the correct address, but a node receiving a commit does not (now) have a way to prove it's the "right" address. For ordinary use that is probably fine, but it's something to take into account if you're considering adding incentives for proposers.

[faustbrian]

I mean specifically ProposerAddress from https://docs.tendermint.com/master/spec/core/data_structures.html#header which has the requirement Must be of length 20 so it shouldn't be an Ed25519 or secp256k1 public key from what I gather based on the above links and contents of the priv_validator_key.json file. The validators array in the genesis.json file also contains an address property which has to match one of the 2 possible derivation methods I linked above and has to be 20 bytes.

I guess one solution would be to store both the Tendermint validator address (ed25519/secp256k1) and application address (bech32, base58, any algo really) so that for application interactions it could use the bech32 address for example but it would also have a way to discover validator accounts based on the Tendermint address.

[creachadair]

I mean specifically ProposerAddress from https://docs.tendermint.com/master/spec/core/data_structures.html#header which has the requirement Must be of length 20

I'm not sure if that matches the implementation, which populates the proposer address here. That is the current implementation, and it's possible it's been changed. I don't think anything is truncating the address, though.

(I'm not sure whether the implementation or the documentation is wrong, but as a general rule if the two disagree they're both wrong 🙂)

[faustbrian]

Oh, so it is indeed the public key in the current implementation and the documentation seems to be outdated. I'll do some logging but I guess then it is safe to assume that I'm getting the public key I can use for any lookups and derivation. I guess this documentation will become irrelevant anyway once the ABCI++ lands?

[creachadair]

Hmm, now that I dig a bit more, I think my claim above may be wrong: The Address method of the public key appears to do the hash/truncation step (example). So perhaps the documentation is correct already.

[faustbrian]

Yeah I just did some logging and I do indeed get the truncated and hashed address so I think I have to stick to option 2 where I store 2 addresses for validator accounts to be able to find their application accounts based on the Tendermint and application address. The use-cases would be to use their Tendermint address to find their account for proposal related incentive tasks like rewards and use their application address for everything else that doesn't rely on Tendermint data.