Smiths: Should be able to changeOwnerKey

Nodes Duniter-v2s
1

Dans une précédente discussion, il a été mentionné que le blocage actuellement fait côté Duniter, empêchant les smiths de migrer leur identité, n’avait probablement plus lieu d’être au vu des évolutions du protocole qui ont été effectuées depuis.

Pensez-vous qu’il serait possible de lever cette restriction avant la migration ?

1 Like
2

Tu veux dire validateur ? Les forgerons ont le droit de faire ça, s’ils n’ont pas été online récemment (depuis ReportLongevity blocs soit 1 semaine).

Je ne sais pas exactement pourquoi la restriction est (ou était) importante, ni si ça a changé, mais même si ça n’a pas changé, on doit pouvoir la contourner puisque le changement de clé est sauvegardé de toute façon. (donc on peut retrouver le malfaiteur s’il change d’adresse, mais à voir comment le dire à Substrate)

3

J’ai pourtant l’impression que tant qu’on est smith, même si on a jamais été online, on ne peut pas changeOwnerKey.

1 Like
4

A priori ça a été corrigé là non ?

1 Like
5

ReportLongevity n’est pas exposé dans les constante du runtime ? Impossible de le connaitre côté outils autrement que hardcoder ?

Attention actuellement la durée des epoch est differente entre gtest (1h) et g1 (4h) je ne sais pas si c’est voulu, mais du coup ReportLongevity sera tout autant différent vue qu’utilisé pour son calcul.

Je croyais qu’on voulais que gtest soit exactement avec les mêmes valeurs que g1. C’est juste qu’on a pas encore configuré les valeurs de g1 ?

Je viens de go offline, j’ai donc un affichage cohérent dans gecko avec des valeurs hardcodés:

image
image389×110 4.38 KB

2 Likes
6

En fait cette valeur est définie dans une constante mais juste utilisée dans le système de signalement des équivocations :

# runtime/gtest/src/parameters.rs
// Babe
pub const EPOCH_DURATION_IN_SLOTS: BlockNumber = HOURS;
parameter_types! {
    pub const EpochDuration: u64 = EPOCH_DURATION_IN_SLOTS as u64;
    pub const ExpectedBlockTime: u64 = MILLISECS_PER_BLOCK;
    pub const ReportLongevity: BlockNumber = 168 * EPOCH_DURATION_IN_SLOTS;
}

# runtime/common/src/pallets_config.rs
impl pallet_babe::Config for Runtime {
    type EquivocationReportSystem =
        pallet_babe::EquivocationReportSystem<Self, Offences, Historical, ReportLongevity>;

Ce type est juste utilisé comme un getter dans le code de babe :

pub struct EquivocationReportSystem<T, R, P, L>(core::marker::PhantomData<(T, R, P, L)>);

impl<T, R, P, L>
	OffenceReportSystem<Option<T::AccountId>, (EquivocationProof<HeaderFor<T>>, T::KeyOwnerProof)>
	for EquivocationReportSystem<T, R, P, L>
where
	T: Config + pallet_authorship::Config + frame_system::offchain::CreateInherent<Call<T>>,
	R: ReportOffence<
		T::AccountId,
		P::IdentificationTuple,
		EquivocationOffence<P::IdentificationTuple>,
	>,
	P: KeyOwnerProofSystem<(KeyTypeId, AuthorityId), Proof = T::KeyOwnerProof>,
	P::IdentificationTuple: Clone,
	L: Get<u64>,
{
	type Longevity = L;

Donc visiblement c’est conçu pour pouvoir être une fonction mais en pratique ça retourne qu’une constante hardcodée. Dans notre cas tu peux hardcoder le 168. D’ailleurs on pourrait changer cette valeur. Ça dépend de notre réactivité à rapporter des équivocations ><
Mais je pense que c’est une attaque un peu sophistiquée et qu’on a d’autres mécanismes de défense contre, donc on pourrait réduire la valeur sans problème.

1 Like