TIP-1017 Validator Config V2 by SuperFluffy · Pull Request #2181 · tempoxyz/tempo

SuperFluffy · 2026-01-20T15:16:48Z

Co-authored-by: dankrad <mail@dankradfeist.de>

Zygimantass · 2026-01-23T12:54:18Z

+at the boundary height:
+
+```
+if chainspec.is_allegro_active_at_timestamp(block.timestamp) {


Suggested change

if chainspec.is_allegro_active_at_timestamp(block.timestamp) {

if chainspec.is_hardfork_active_at_timestamp(contract_upgrade_hardfork, block.timestamp) {

Why the extra contract_upgrade_hardfork argument?

…e addresses

## Summary **Manual migration**: Admin migrates validators one at a time via `migrateValidator(valIdx)`, then calls `initialize()` to flip the flag. CL reads from V1 until the flag is set. | Change | Description | |--------|-------------| | **Read before init** | CL reads directly from V1 (no proxying in V2) | | **migrateValidator(valIdx)** | Migrates single validator; copies owner on first call; reverts if `valIdx != validatorsArray.length` | | **initialize()** | Copies `nextDkgCeremony` from V1, sets `initialized = true` | | **Active validators** | `addedAtHeight = 0`, `deletedAtHeight = 0` | | **Inactive validators** | `addedAtHeight = deletedAtHeight = block.timestamp` | | **Filter logic** | `v.addedAtHeight <= H && (deletedAtHeight == 0 \|\| deletedAtHeight > H)` | ## Migration Steps (Existing Networks) 1. Release new node software with Allegro hardfork support 2. Schedule the fork by updating chainspec with target `allegroTime` 3. At fork activation: CL reads from V1 (since `isInitialized() == false`) 4. Admin migrates validators: `migrateValidator(0)`, `migrateValidator(1)`, ... 5. Admin calls `initialize()` → sets `initialized = true`, CL reads from V2 6. Post-migration: All reads/writes use V2 state directly ## New Networks 1. Initialize V2 at genesis with the initial validator set (set `initialized = true`) 2. Set `allegroTime = 0` to activate V2 immediately 3. V1 Validator Config contract/precompile is not necessary --------- Co-authored-by: Amp <amp@ampcode.com> Co-authored-by: Richard Janis Goldschmidt <github@aberrat.io> Co-authored-by: Tanishk Goyal <goyaltanishk02@gmail.com>

malleshpai · 2026-02-07T22:45:11Z

+    function deactivateValidator(address validatorAddress) external;
+
+    /// @notice Rotate a validator to a new identity (owner or validator only)
+    /// @dev Atomically deletes the specified validator entry and adds a new one. This is equivalent


If you do it this way, and I rotate a validator mid-epoch, i would be ineligible to participate in the next DKG right? is that intentional? the fact that you're saying it is equivalent to delete and then add suggests that it is intentional, but given our current thin margins is this safe (we might have too few players available for the next dkg)

nevermind now i understand. it might be worth explaining to validators that rotation involves a one epoch worth of deactivation (if it wasn't explained somewhere that i missed) but i think no change needed here.

maybe worth a test case?

It is briefly explained in the doc, but I agree - we should make this part of the docs so people understand.

But you pointing this out raises a point about how this spec wants to make deactivation immediate while leaving 1 epoch to warmup the new validator:

in epoch E: call rotateValidator($old, $new)

in epoch E+1: $old leaves the set of players (it is still a validator + dealer in this epoch); $new is not a player, merely registered as a peer and receives votes and certificates allowing it to sync up

in epoch E+2: $old dropped out of the committee; $new is a player and will receives shares from the other dealers to acknowledge

in epoch E+3: $new is in the committee.

This means there is a forced downtime of 1 epoch.

malleshpai · 2026-02-07T23:00:21Z

+14. **Address update**: `transferValidatorOwnership` updates the address of an existing
+    validator without changing any other fields. This is useful for updating
+    addresses post-migration or correcting address assignments.
+


this clashes with invariant 2?

Good catch! I updated invariant 2 and moved 14 into position 3 to clarify this point: validatorAddress is only mutable by the contract owner to address post-migration fixes. It cannot be changed by the owner of the entry.

c01f841

malleshpai · 2026-02-07T23:15:08Z

+    function deactivateValidator(address validatorAddress) external;
+
+    /// @notice Rotate a validator to a new identity (owner or validator only)
+    /// @dev Atomically deletes the specified validator entry and adds a new one. This is equivalent


maybe worth a test case?

malleshpai · 2026-02-07T23:45:34Z

+8. **Historical consistency**: For any height H, the active validator set
+   consists of validators where `addedAtHeight <= H && (deactivatedAtHeight == 0 ||
+   deactivatedAtHeight > H)`. Validators with `addedAtHeight == deactivatedAtHeight` are
+   never considered active.


should add !=0 here right? otherwise you rule out migrated vals...

Thank you once more. This, too, was incorrect. addedAtHeight = block.height always: f80ecc4

malleshpai · 2026-02-08T00:30:29Z

+))
+```
+
+The old validator is identified by `msg.sender`, which must be an existing active validator.


i think this contradicts invariant 11?

Removed that comment - unnecessary and confusing: d57544c

malleshpai · 2026-02-08T00:36:42Z

+
+---
+
+# Invariants


Amp suggested this: "For validators added via addValidator, addedAtHeight > 0. addedAtHeight == 0 is reserved for validators migrated from V1

I changed this in f80ecc4: addedAtHeight is now always set to block.height. While this might be confusing for historical backlook, this is fine from CL's point of view because we only care about looking forward.

…n/deletion of validators

SuperFluffy · 2026-02-09T16:06:32Z

+**Validator Addition and Deactivation**: When validators are added or deleted (this also applies to rotation),
+there is no warmup period: deactivated validators are immediately removed from the set of players on the next epoch,
+while activated validators are immediately added on the next epoch. This means that compared to validator config V1,
+there is no cooldown and no warmup period.


@Zygimantass for confirmation: there is no cooldown and warmup period anymore.

Prepares peer management for the changes in #2181 (TIP 1017) by moving it to a self standing actor: after the hardfork, it will check every finalized block for changes to IP addresses in the peer set and update its tracked peers accordingly. For now there are no other changes other than delegating messages to the peer manager to its wrapped p2p oracle.

… state (#2638) Migrates the DKG actor's state from a continuous journal to a `Metadata` object. The journal had unnecessary extra complexity that was not needed. The `Metadata` object is simpler to reason about. This migration is non-breaking: the journal is migrated to metadata and deleted. If a metadata object is already present it is not overwritten. As part of the migration, the DKG actor no longer tracks the socket addresses of dealers and players. This information is available in the execution layer state and can be read from there. These changes are in preparation for the Validator Config V2 where address tracking will be moved out of the DKG actor. Related #2181, #2617

Moves peer handling from the DKG actor and into the peer manager. In preparation for the val config V2 changes introduced in TIP 1017. Related: #2181 #2617

SuperFluffy force-pushed the janis/val-cfg-v2 branch 2 times, most recently from e61f62b to 9824220 Compare January 20, 2026 17:26

SuperFluffy changed the title ~~WIP: TIP-1008~~ WIP: TIP-XXXX Validator Config V2 Jan 20, 2026

jenpaff reviewed Jan 20, 2026

View reviewed changes

Comment thread tips/tip-1017.mdx

SuperFluffy force-pushed the janis/val-cfg-v2 branch 3 times, most recently from 920281b to 983e145 Compare January 21, 2026 13:12

SuperFluffy commented Jan 21, 2026

View reviewed changes

Comment thread tips/tip-1017.mdx

SuperFluffy commented Jan 21, 2026

View reviewed changes

Comment thread docs/pages/protocol/tips/tip-xxxx.mdx Outdated

WIP: TIP-XXXX, Validator Config V2

7ec1892

SuperFluffy force-pushed the janis/val-cfg-v2 branch from 983e145 to 7ec1892 Compare January 21, 2026 13:27

dankrad reviewed Jan 21, 2026

View reviewed changes

Comment thread docs/pages/protocol/tips/tip-xxxx.mdx Outdated

dankrad reviewed Jan 21, 2026

View reviewed changes

Comment thread tips/tip-1017.mdx

SuperFluffy and others added 2 commits January 22, 2026 12:53

Update docs/pages/protocol/tips/tip-xxxx.mdx

3f43658

Co-authored-by: dankrad <mail@dankradfeist.de>

add domain separation

cbf2d15

SuperFluffy force-pushed the janis/val-cfg-v2 branch from 57d29ca to cbf2d15 Compare January 22, 2026 12:31

legion2002 reviewed Jan 23, 2026

View reviewed changes

Comment thread tips/tip-1017.mdx

Comment thread docs/pages/protocol/tips/tip-xxxx.mdx Outdated

Comment thread docs/pages/protocol/tips/tip-xxxx.mdx Outdated

Comment thread tips/tip-1017.mdx

Comment thread docs/pages/protocol/tips/tip-xxxx.mdx Outdated

Comment thread tips/tip-1017.mdx

Zygimantass reviewed Jan 23, 2026

View reviewed changes

Comment thread tips/tip-1017.mdx

Zygimantass reviewed Jan 23, 2026

View reviewed changes

Comment thread docs/pages/protocol/tips/tip-xxxx.mdx Outdated

Zygimantass reviewed Jan 23, 2026

View reviewed changes

howydev reviewed Jan 26, 2026

View reviewed changes

Comment thread docs/pages/protocol/tips/tip-xxxx.mdx Outdated

howydev reviewed Jan 26, 2026

View reviewed changes

Comment thread tips/tip-1017.mdx

howydev reviewed Jan 26, 2026

View reviewed changes

Comment thread docs/pages/protocol/tips/tip-xxxx.mdx Outdated

howydev reviewed Jan 27, 2026

View reviewed changes

Comment thread docs/pages/protocol/tips/tip-xxxx.mdx Outdated

add a function to rotate validators

126563d

howydev reviewed Jan 27, 2026

View reviewed changes

Comment thread tips/tip-1017.mdx

SuperFluffy and others added 4 commits January 28, 2026 12:47

use zero-indexing for contract address, egress/ingress to disambiguat…

0388267

…e addresses

precompile address is 0XCCCC...0001

e358695

add motivation for manual migration

e6c59f5

SuperFluffy force-pushed the janis/val-cfg-v2 branch from 8c6d695 to 5160339 Compare February 6, 2026 15:06

howydev approved these changes Feb 6, 2026

View reviewed changes

hamdiallam approved these changes Feb 6, 2026

View reviewed changes

malleshpai reviewed Feb 7, 2026

View reviewed changes

malleshpai approved these changes Feb 8, 2026

View reviewed changes

SuperFluffy added 6 commits February 9, 2026 15:46

clarify address invariants

c01f841

replace block.timestamp by block.height, where appropriate

f381809

on migration, addedAtHeight = block.height

f80ecc4

remove unnecessary comment

d57544c

add a field initializedAtHeight

cc1e77e

update expected consensus layer behavior to reflect immediate additio…

ee47582

…n/deletion of validators

SuperFluffy commented Feb 9, 2026

View reviewed changes

minor fixes and incosistencies

d40fe07

SuperFluffy enabled auto-merge February 9, 2026 16:26

SuperFluffy added this pull request to the merge queue Feb 9, 2026

github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Feb 9, 2026

SuperFluffy added this pull request to the merge queue Feb 9, 2026

github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Feb 9, 2026

SuperFluffy added this pull request to the merge queue Feb 9, 2026

Merged via the queue into main with commit 1f1aed7 Feb 9, 2026
21 of 23 checks passed

SuperFluffy deleted the janis/val-cfg-v2 branch February 9, 2026 17:39

This was referenced Feb 11, 2026

refactor(consensus): move peer tracking to self standing actor #2617

Merged

refactor(consensus): migrate DKG to use metadata, remove IPs from DKG state #2638

Merged

SuperFluffy mentioned this pull request Feb 13, 2026

chore(consensus): move all peer handling to peer manager #2696

Merged

	if chainspec.is_allegro_active_at_timestamp(block.timestamp) {
	if chainspec.is_hardfork_active_at_timestamp(contract_upgrade_hardfork, block.timestamp) {


		---

		# Invariants

Conversation

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

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SuperFluffy Feb 5, 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!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

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!

Choose a reason for hiding this comment

Uh oh!

SuperFluffy Feb 9, 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!

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

SuperFluffy commented Jan 20, 2026 •

edited

Loading

SuperFluffy Feb 5, 2026 •

edited

Loading

SuperFluffy Feb 9, 2026 •

edited

Loading