You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
FRAME's pallets are being used for relay-chain as well as parachain implementations.
In many instances, the word Validator is used to name variables, traits, enums, etc. For the cases where the pallet is only expected to be used in a relay-chain context, that is usually fine (e.g.: staking and nomination-pools pallets).
However, there's many cases where the FRAME pallets are also used in a parachain context. The use of Validator terminology is potentially misleading there, because it's not obvious that Validator terms should actually be interpreted as Collator under those circumstances.
That can be even more misleading in the case of system-level parachains (cc @joepetrowski). A naive reader could maybe interpret those variables as something related to the relay-chain validators, or (even worse) simply equate Validators to Collators as if their concepts were actually identical.
I've actually witnessed the second scenario in our ecosystem recently (not really system parachain-related though). While it's not not our job to hold the hand of every naive developer, I still think there's room for us to decrease the potential for cognitive dissonances for developers diving into our codebase with fresh eyes.
Here's a list of FRAME pallets where I was able to detect the term Validator being used interchangeably with Collator (can be interpreted both ways, depending on context):
session
babe
aura
executive
im-online
On the Cumulus side, collator-selection pallet is using Validator where Collatoris the only possible interpretation. The only reason for that seems to be the fact that it imports frame_support::traits::ValidatorRegistration and all the other variables follow that as a convention.
A potential solution would be to rename FRAME's support::traits::validation module to something like support::traits::author, as well as all its Validator* variables (traits, etc) to Author*. That would impose a more generic naming convention on all the pallets listed above, removing the potential for contextual misinterpretations.
FRAME's pallets are being used for relay-chain as well as parachain implementations.
In many instances, the word
Validator
is used to name variables, traits, enums, etc. For the cases where the pallet is only expected to be used in a relay-chain context, that is usually fine (e.g.:staking
andnomination-pools
pallets).However, there's many cases where the FRAME pallets are also used in a parachain context. The use of
Validator
terminology is potentially misleading there, because it's not obvious thatValidator
terms should actually be interpreted asCollator
under those circumstances.That can be even more misleading in the case of system-level parachains (cc @joepetrowski). A naive reader could maybe interpret those variables as something related to the relay-chain validators, or (even worse) simply equate Validators to Collators as if their concepts were actually identical.
I've actually witnessed the second scenario in our ecosystem recently (not really system parachain-related though). While it's not not our job to hold the hand of every naive developer, I still think there's room for us to decrease the potential for cognitive dissonances for developers diving into our codebase with fresh eyes.
Here's a list of FRAME pallets where I was able to detect the term
Validator
being used interchangeably withCollator
(can be interpreted both ways, depending on context):session
babe
aura
executive
im-online
On the Cumulus side,
collator-selection
pallet is usingValidator
whereCollator
is the only possible interpretation. The only reason for that seems to be the fact that it importsframe_support::traits::ValidatorRegistration
and all the other variables follow that as a convention.A potential solution would be to rename FRAME's
support::traits::validation
module to something likesupport::traits::author
, as well as all itsValidator*
variables (traits, etc) toAuthor*
. That would impose a more generic naming convention on all the pallets listed above, removing the potential for contextual misinterpretations.Cumulus companion: #73
The text was updated successfully, but these errors were encountered: