feat(consensus): make consensus aware of TIP 1017 by SuperFluffy · Pull Request #2716 · tempoxyz/tempo

SuperFluffy · 2026-02-16T18:01:59Z

requires #2696 and ~~#2635~~

github-actions · 2026-02-16T18:02:46Z

⚠️ Changelog not found.

A changelog entry is required before merging. We've generated a suggested changelog based on your changes:

Preview

---
tempo-commonware-node: minor
---

Added support for reading validator configuration from ValidatorConfigV2 contract after T2 hardfork. The DKG manager and peer manager now dynamically read from V1 or V2 contracts based on block timestamp and initialization status, enabling seamless validator set transitions across the hardfork.

Add changelog to commit this to your branch.

github-actions · 2026-02-16T18:13:16Z

📊 Tempo Precompiles Coverage

📦 Download full HTML report

…stically; if it can't -> read on the next attempt

joshieDo · 2026-02-18T12:39:45Z

crates/commonware-node/src/validators.rs

+        .is_t2_active_at_timestamp(header.timestamp())
+        && is_v2_initialized(node, header.number())
+            .wrap_err("failed reading validator config v2 initialization flag")?
+        && v2_initialization_height(node, header.number())


couldnt these two be unified somehow? we're instantiating the precompile twice for the same height i think?

Yeah, that's true.

joshieDo · 2026-02-18T12:40:15Z

crates/e2e/src/tests/backfill.rs

+        let metric = parts.next().unwrap();
+        let value = parts.next().unwrap();
+
+        if metrics.ends_with("_peers_blocked") {


Suggested change

if metrics.ends_with("_peers_blocked") {

if metric.ends_with("_peers_blocked") {

crates/commonware-node/src/consensus/application/actor.rs

joshieDo · 2026-02-18T12:47:26Z

crates/commonware-node/src/dkg/manager/actor/mod.rs

+        let read_players_from_v2_contract = Counter::default();
+        context.register(
+            "read_players_from_v2_contract",
+            "the number of times the players were read from the validator config v1 contract",


Suggested change

"the number of times the players were read from the validator config v1 contract",

"the number of times the players were read from the validator config v2 contract",

crates/commonware-node/src/peer_manager/actor.rs

joshieDo · 2026-02-18T13:00:24Z

crates/commonware-node/src/peer_manager/actor.rs

+        .wrap_err("provider does not have best block available")?;
+
+    ensure!(
+        best_block_number >= reference_header.number(),


are there weird scenarios here?

eg. imagine that validator is observing the network (not catching up), and EL is ahead (non finalized block), we construct the peer set from this block, which then ends up reorged (and lets say without the new validator state). Does it "reset" in the next finalized block?

Good point. In #2750 I am actually running a read_validator_config_at_hash to prevent this scenario. read_validator_config is only used for the best block - but I should rename it to make it clearer.

Should we pull those changes into this PR?

I can. I decided to not push into this PR so there is no churn while reviewing.

Then we can remove all non-blockhash based reads?

They are still valuable for startup.

But ye - probably makes sense to go over all reads and determine if reading heights is ok

Co-authored-by: joshieDo <93316087+joshieDo@users.noreply.github.com>

hamdiallam · 2026-02-18T17:57:50Z

crates/commonware-node/src/peer_manager/actor.rs

+        };
+        self.oracle
+            .track(
+                last_tracked_peer_set.height,


We need to revisit the PEERSETS_TO_TRACK constant as I believe this change will now exhibit different behavior.

Previously, maintained peers 3/4 epochs back.

Now will only maintain peers 3/4 blocks back

That is true - although I have to admit that I am not sure what the value of tracking several peersets is at all anymore, to be honest.

Note that it only pushes a new peer set if a new entry was added (usually addValidator or rotateValidator) or if an entry was removed (deleteValidator followed by a validator dropping out of the peer set). If the peer set remains stable but the IPs change, then the latest set is just overwritten.

For additions, makes sense to not need to track backwards.

For removals, active=false and will be removed from the latest peerset. However this validator still needs to participate in DKG until being fully removed? If there are a couple of updates (add/removes) then this validator would prematurely get evicted?

Oh no, we always take into account those peers that are mentioned in the last DKG outcome (copied this from the PR because linking to github diffs is miserable):

let all_keys = outcome .dealers() .iter() .chain(outcome.next_players().iter()) .chain(match validators { Validators::V1(validators) => Either::Left( validators .iter_pairs() .filter_map(|(k, v)| v.is_active().then_some(k)), ), Validators::V2(validators) => Either::Right( validators .iter_pairs() .filter_map(|(k, v)| v.is_active().then_some(k)), ), });

^ This ensures that we always track the validators mentioned in the DKG outcome, as well as whichever validators are active as per the on-chain state.

With that said, there is a bug - I should be chaining outcome.players() not outcome.dealers() (these are the dealers that helped construct the outcome, giving new shares to the players).

so good thing we had a second look at that.

See 378622c

Gotcha! makes sense

…* dealers

hamdiallam

LGTM!

If we add some metrics on peerset address updates. This is different than the number of peers, then we should also be able to e2e test address updates being processed when a validator updates their IP onchain

…d blocks at hashes; add metrics

SuperFluffy force-pushed the janis/reconcile-in-peer-actor branch from f2cff56 to df28fa3 Compare February 17, 2026 13:13

SuperFluffy changed the base branch from janis/reconcile-in-peer-actor to tmp-val-cfg-v2-base February 17, 2026 13:23

SuperFluffy force-pushed the janis/v2-peersets branch from 1e523ec to 8998566 Compare February 17, 2026 13:23

SuperFluffy added 6 commits February 17, 2026 19:34

DecodedValidator -> DecodedValidatorV1

a676736

peer manager reads from val config v1 or v2 depending on block timestamp

7ccb1f4

dkg actor reads from v1 or v2, depending on initialization status

dfd2586

update peer sets on every block, but only if they changed

df1d667

debug tests - peer manager only needs to read finalized blocks optimi…

27515db

…stically; if it can't -> read on the next attempt

clean up reading from contracts; add metrics

c4bfeda

SuperFluffy force-pushed the janis/v2-peersets branch from ec93241 to c4bfeda Compare February 17, 2026 18:34

SuperFluffy changed the base branch from tmp-val-cfg-v2-base to janis/reconcile-in-peer-actor February 17, 2026 18:34

SuperFluffy marked this pull request as ready for review February 17, 2026 23:49

SuperFluffy requested review from hamdiallam and joshieDo as code owners February 17, 2026 23:49

joshieDo reviewed Feb 18, 2026

View reviewed changes

crates/commonware-node/src/peer_manager/actor.rs Outdated Show resolved Hide resolved

joshieDo reviewed Feb 18, 2026

View reviewed changes

crates/commonware-node/src/peer_manager/actor.rs Outdated Show resolved Hide resolved

joshieDo reviewed Feb 18, 2026

View reviewed changes

SuperFluffy changed the title ~~[WIP] feat(consensus): make consensus aware of TIP 1017~~ feat(consensus): make consensus aware of TIP 1017 Feb 18, 2026

typos found by @joshie

4f2f6bf

Co-authored-by: joshieDo <93316087+joshieDo@users.noreply.github.com>

hamdiallam reviewed Feb 18, 2026

View reviewed changes

outcome.players are the current dealers, outcome.dealers are the *old…

378622c

…* dealers

hamdiallam approved these changes Feb 18, 2026

View reviewed changes

SuperFluffy added 2 commits February 19, 2026 13:20

peer manager reads finalized block only after executor delivered; rea…

e939e7f

…d blocks at hashes; add metrics

nits

6dbbedd

	if metrics.ends_with("_peers_blocked") {
	if metric.ends_with("_peers_blocked") {

	"the number of times the players were read from the validator config v1 contract",
	"the number of times the players were read from the validator config v2 contract",

Comments

Conversation

SuperFluffy commented Feb 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Feb 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

⚠️ Changelog not found.

Uh oh!

github-actions bot commented Feb 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

📊 Tempo Precompiles Coverage

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hamdiallam Feb 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hamdiallam Feb 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hamdiallam left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

SuperFluffy commented Feb 16, 2026 •

edited

Loading

github-actions bot commented Feb 16, 2026 •

edited

Loading

github-actions bot commented Feb 16, 2026 •

edited

Loading

hamdiallam Feb 18, 2026 •

edited

Loading

hamdiallam Feb 18, 2026 •

edited

Loading

hamdiallam left a comment •

edited

Loading