Distance client: search for the right key

added C-binary P5-sometimesoon RN-binary S-ToDo bug labels

Obtaining the node's owner key from the client is not obvious.

In the runtime, when using BABE, the author's owner key is found from the author's index in the validator set. This id is obtained from the block's digest with the key BABE (see the functions find_author in the pallets authorship, session and babe). Knowing that should help finding where this id is found when building the block.

My understanding, developing a bit on what you just wrote:

when a smith publishes an evaluation result within an inherent, it uses an AccountId to identify himself:

let author = pallet_authorship::Pallet::<T>::author().ok_or(Error::<T>::NoAuthor)?;

This function author() reads the storage value of Author which is a temporary value that changes within a block but is always erased on on_finalized. If this storage value has not been written, it calls the FindAuthor::find_author() method of configured FindAuthor.

With our current config of FindAuthor, this is pallet_session::FindAccountFromAuthorIndex<Self, Babe>;. This leads to call the find_author() method of Babe.

find authority_index index
get the item at this position in Validators storage

This indeed returns the value that we put here. See #197 (closed) for why I was uncomfortable with that.

at each block, the smith calls InherentDataProvider which can return Some(result) or None, the inherent is only called if Some result:

.map(|inherent_data| Call::update_evaluation { computation_result: inherent_data })

With this architecture, it is the InherentDataProvider which is responsible to tell whether or not a result has been published (it is fine, we do not want to do this in the runtime). It currently tries to achieve this by checking if any of the keys present in published_results is present in local list:

let babe_owner_keys =
    std::sync::Arc::new(sp_keystore::Keystore::sr25519_public_keys(
        keystore_ptr.as_ref(),
        sp_runtime::KeyTypeId(*b"babe"),
    ));
// .map(|&key| sp_runtime::AccountId32::new(key.0))

There is no chance that the babe owner key transformed into an AccountId is present in the Validator set, because babe owner keys are simple delegated keys while validator keys correspond to the account of the smith's identity.

Thus, we have to find a way for the inherent data provider to be informed on the key of the smith.

It is as simple as calling:

session.keyOwner(babe, 0x5a172f9a6759763f59a7e0a4d170b467b744eabb3adb454f38a2e7957fb9cd28)
5CfdJjEgh3jDkg3bzmZ1ED1xVhXAARtNmZJWbcXh53rU8z5a

What I suggest:

look which one of the locally available BABE keys is currently online by looking in babe.authorities()
find the validator AccountId associated with this particular key with session.keyOwner(babe, <key>)
browse results as before to look at this particular key

Do you want/have time to handle that or do you prefer to let me do it and simply review?

I can do it this week-end.

Good thing you've found the function keyOwner!

assigned to @tuxmain

mentioned in merge request !291 (merged)

added S-needreview label and removed S-ToDo label

closed with merge request !291 (merged)

Distance client: search for the right key

Child items ...

Activity