Closed ermalkaleci closed 11 months ago
setValidationData is executed first so other inherent can read proofs from query.parachainSystem.relayStateProof()
@girazoki
thank you!
@ermalkaleci as I am understanding it, now every key that was proven from the previous block and that is not modified will be included and proved on the new built block?
yes, you don't need to touch SetValidationData
inherent. SetValidationData will be executed first and set new proofs which you can read on your inherent from query.parachainSystem.relayStateProof()
ah that's amazing. I think it does cover most of our needs so we will shortly propose a PR adding tanssi support. The only thing I am thinking is: what happens if there are some keys being proved in one inherent (set-validation-data) and others in another inherent (authorities-noting in our case) in production? Probably the nibbles passed to set-validation-data do not include all keys to be able to fork correctly.
We might propose the possibility to add additional keys to set-validation-data inherent if that's fine in the PR that supports tanssi (in other words, being able to add additional keys to the WellKnownKeys
struct)
the other thing we can do is refactor our node to inject a single proof (in set-validation-data) that contains all keys we need to prove. That should work with this implementation and I think its cleaner! So in that case you dont need to worry about what I just said :)
I think I was wrong. I will look again tomorrow, maybe it needs a refactor
this will make it easy to implement new inherent #561 decode_proof will find all possible keys so there's no need to inject unchanged ones