Simplify getting the block author.
Seeing questions like: https://substrate.stackexchange.com/questions/5394/how-to-get-the-current-block-author/5395#5395
I wonder, wouldn't it make the world easier for everyone if we make sure the small bit of logic that extracts authorship data from the header is extracted before all pallets (i.e. in executive or system) and then make the current block author a storage item in the system?
I think reading the block author should be as simple as reading the current block height, available to all pallets by default.
Is this going to check a signature too? Or assume the block was already imported?
Is this going to check a signature too? Or assume the block was already imported?
No this isn't about signature checking. Just to get the block author if the current block.
I wonder, wouldn't it make the world easier for everyone if we make sure the small bit of logic that extracts authorship data from the header is extracted before all pallets (i.e. in executive or system) and then make the current block author a storage item in the system?
I'm clearly against this. The solution to none of our problems should be that we add stuff to the System, if we can prevent this. System already carries to much data and associated types etc. Another point here would also be that there can exist a block authoring (and it already exists) where you don't know the author/there is no strict requirement to know the author.
Either already imported, or being authored by validator x.
In both cases, we only need an account id.
in a case where the block dont have an author we should just return None. I think knowing block author's account's Id may come into use inside runtime.
Either already imported, or being authored by validator x.
In both cases, we only need an account id.
Yes for sure. However, I'm still not convinced that this should live in System. We should improve the docs to make it more clear on how to get this data.
Either already imported, or being authored by validator x. In both cases, we only need an account id.
Yes for sure. However, I'm still not convinced that this should live in
System. We should improve the docs to make it more clear on how to get this data.
I just think for 99.99% of the cases, any blockchain, at any given context has a block author. Do you have a common example where this does not hold? otherwise I could take your argument and extract things like weight and length from system as well.
I'd expect drand "blocks" have no block author, so it's plausible block author makes little sense in other threshold signed schemes (think ICP/dFinity). I think wacky dag merge schemes could do multiple block authors, or maybe no block author.
We only design SSLEs to anonymize block producers only before block production, but actually shuffle SSLEs or sassafras could be adapted to anonymize block authors after block production too, which maybe relevant after the tornado cash case. In sassafras, you merely replace the non-anonymous block VRF signature with a second ring VRF signature whose auxiliary data contains the header. You'll loose much anonymity from large blocks going over the network layer, but you'll have something ala Tor.
otherwise I could take your argument and extract things like weight and length from system as well.
If you find a proper way, please do it :heart:
I just think for 99.99% of the cases, any blockchain, at any given context has a block author.
https://github.com/paritytech/cumulus/blob/master/client/consensus/relay-chain/src/lib.rs this here doesn't has any author. I mean, yes there is a node that builds it. However, there is no requirement that this node is having any session key or whatever on chain. So, there also doesn't exist any account id.