Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

Increase priority of ImOnline heartbeats #3972

Merged
merged 2 commits into from
Oct 30, 2019
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion node/runtime/src/lib.rs
Original file line number Diff line number Diff line change
Expand Up @@ -82,7 +82,7 @@ pub const VERSION: RuntimeVersion = RuntimeVersion {
// implementation changes and behavior does not, then leave spec_version as
// is and increment impl_version.
spec_version: 190,
impl_version: 190,
impl_version: 191,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this change actually alters behavior of the runtime it looks like the spec_version should be bumped as well.

apis: RUNTIME_API_VERSIONS,
};

Expand Down
3 changes: 2 additions & 1 deletion srml/im-online/src/lib.rs
Original file line number Diff line number Diff line change
Expand Up @@ -80,6 +80,7 @@ use sr_primitives::{
traits::{Convert, Member, Printable, Saturating}, Perbill,
transaction_validity::{
TransactionValidity, TransactionLongevity, ValidTransaction, InvalidTransaction,
TransactionPriority,
},
};
use sr_staking_primitives::{
Expand Down Expand Up @@ -532,7 +533,7 @@ impl<T: Trait> support::unsigned::ValidateUnsigned for Module<T> {
}

Ok(ValidTransaction {
priority: 0,
priority: TransactionPriority::max_value(),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there anything to stop validators from issuing too many heartbeats?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Had the same question. My second thought was that this might be a common problem among operational transactions.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since provides tag is (current_session, authority_id) there can exist only one such transaction in the pool. The authority could spam transactions from different sessions (or from different authority_id) but they should be rejected through validation. So there can only be as much heartbeats in the pool as there is authorities. If the heartbeat is included in block it should invalidate duplicates from being included.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, thanks for the clarification.

requires: vec![],
provides: vec![(current_session, authority_id).encode()],
longevity: TransactionLongevity::max_value(),
Expand Down