-
Notifications
You must be signed in to change notification settings - Fork 2.6k
let initialize
function in pallet-grandpa/pallet-babe and other session managed pallets be pub
#14555
Comments
The grandpa implementation is setting also the session id, which you probably don't want to do after genesis. I get your problem, but not sure if we don't need like extra functions. We would also need to check if you can just change the authorities or if there are other invariants that assume that this happens after some time. |
emmm in fact without session, for not pallet-grandpa already can replace to next authorities for now, so the |
(Just some ideas... I may overlooked some details so experimentation is required) When we change the authority set in a pallet we are creating a new session. Per-se (at high level) this session concept is detached from the detail that it may be driven via the session-pallet Indeed the So my first suggestion would be to let the pallet perform all its (encapsulated) logic when the authority set (aka session) changes. By brutally setting only the authorities you may end up missing some important logic that the pallet require to perform (and that may change over time). Thus, to let the pallet do its logic, I'd suggest to use the The problem here is that it requires your Pallet to implement So at this point you need to remove the requirement that your pallet should implement the I suggest to use an associated type called (in
|
This may be also a step towards #14198 (further detach consensus algorithms from session pallet) |
Is there an existing issue?
Experiencing problems? Have you tried our Stack Exchange first?
Motivation
In substrate, manage
pallet-grandpa
/pallet-babe
/pallet-aura
and other similar pallets are all managed by Session traitOneSessionHandler
. And this trait just can be called by pallet-session.In solo-chain, parachain, most of chain may use the session to manage keys.
However in other case, like in consortium chain(permission chain), layer2 sequence(like https://github.com/keep-starknet-strange/madara) and other cases, we do not need the pallet-session and related trait to manage those keys, for example in our case, we just need
pallet-aura
andpallet-grandpa
, so we set those two keys directly. Using session to manage keys is useless for us.Request
Above all, we can find that writing another way to manage keys rather then pallet-session in some cases is necessary, so we hope those pallets let related function be
pub
.But for now, just pallet-aura let the function
initialize_authorities
bepub
:substrate/frame/aura/src/lib.rs
Lines 197 to 204 in edf58dc
other pallets, like pallet-grandpa, the
initialize
is notpub
substrate/frame/grandpa/src/lib.rs
Lines 514 to 524 in edf58dc
So at least for the
initialize
part, if this part ispub
, we can write other pallet to manage thosekeys
for init step, rather then impl traitOneSessionHandler
.Solution
go through the pallets, I think we need to let following pallet changing the init function be
pub
necessary:
pallet-grandpa
pallet-babe
not very necessary:
pallet-im-online
pallet-authority-discover
Are you willing to help with this request?
Yes!
The text was updated successfully, but these errors were encountered: