Add Validator for remote L1 without importing blockchain #2607

sukantoraymond · 2025-02-14T18:48:52Z

Enables add validator for remote L1s using avalanche blockchain addValidator command.

This PR introduces importL1() command, which enables commands like addValidator to interact with remote L1s without having to have L1 sidecar.json in local machine. User will need to supply subnet id and rpc url and importL1() will get blockchainID, if PoA/PoS, validatorManagerAddress, validatorManagerOwner on-chain.

This PR also enables users to set the weight of the validator to be added, either through prompt or flag --weight.

importL1() function can be extended to other parts of the codebase: blockchain removeValidator, contract initValidatorManager

Signed-off-by: sukantoraymond <[email protected]>

pkg/constants/constants.go

pkg/validatormanager/validatormanager.go

felipemadero · 2025-02-24T20:59:48Z

pkg/validatormanager/validatormanager.go

+	rpcURL string,
+	managerAddress common.Address,
+) bool {
+	out, err := contract.CallToMethod(


can you check before this, by calling a PoA method, that this is a validator manager and that there is a contract on that direction?

not needed imo, it will fail anyways down the line if contract doesnt exist

it is needed. you need to check for error, to clasify between:

PoA

PoS

nothing is there, or any other smart contract

If not, you are assuming something is PoS and can be nothing

getSubnet returns if subnet is permissioned or not permissioned and the validator manage raddress. If not permissioned and contains validator manager address, it has to mean that the l1 either contains poa or pos. Either way i can't find a good way to determine if poa validator manager exists. Feel free to implement in separate pr. #2635

for sure. function should be general, instead of assuming particular origin of the input contract (the general
idea for this function is not always to call it after a getSubnet).
it should really return an enum including: PoS, PoA, UnknowContract, NoContract

cmd/blockchaincmd/add_validator.go

felipemadero · 2025-02-24T21:43:06Z

cmd/blockchaincmd/add_validator.go

+			return fmt.Errorf("use avalanche addValidator <subnetName> command to use local machine as new validator")
+		}
+		var subnetID ids.ID
+		if subnetIDstr == "" {


you can use the rpc endpoint to get the blockchain id (using warp) and the get the subnet if from the
blockchain id

I should go into that direction if you are to easy the users way

if warp not available, ask for the subnet id (but you can also ask for the blockchain id and get the subnet id from it)

I ignore which is best if subnet id or blockchain id

can u make pr to get blockchain id from rpc endpoint using warp

then you can call contract.GetSubnetID to obtain the subnet id from the chain id

ofc this mail fail if warp if disabled, so, on error, you default to ask for subnet id (or blockchain id). prompt order to be first rpc then subnet id if warp query fails

will impleent this once #2633 is merged into main.

cmd/blockchaincmd/deploy.go

cmd/blockchaincmd/add_validator.go

learyce · 2025-02-25T20:15:59Z

cmd/blockchaincmd/add_validator.go

@@ -119,31 +122,50 @@ Testnet or Mainnet.`,
 	cmd.Flags().StringVar(&outputTxPath, "output-tx-path", "", "(for Subnets, not L1s) file path of the add validator tx")
 	cmd.Flags().BoolVar(&waitForTxAcceptance, "wait-for-tx-acceptance", true, "(for Subnets, not L1s) just issue the add validator tx, without waiting for its acceptance")
 	cmd.Flags().Uint16Var(&delegationFee, "delegation-fee", 100, "(PoS only) delegation fee (in bips)")
+	cmd.Flags().StringVar(&subnetIDstr, "subnet-id", "", "subnet ID (only if blockchain name is not provided)")


(Not about this PR) But the strings here, was it a deliberate choice not to move the strings here into constants or more so something that just grew this way?

we can technically move all the flags that we have into a separate file like flags.go and have var for all the flags we use. This is a tech debt

There are some parts of code where the flags names are constants. But overall, it grew this way. We need
to improve (or have) code standards here.

learyce · 2025-02-25T20:22:33Z

cmd/blockchaincmd/add_validator.go

@@ -119,31 +122,50 @@ Testnet or Mainnet.`,
 	cmd.Flags().StringVar(&outputTxPath, "output-tx-path", "", "(for Subnets, not L1s) file path of the add validator tx")
 	cmd.Flags().BoolVar(&waitForTxAcceptance, "wait-for-tx-acceptance", true, "(for Subnets, not L1s) just issue the add validator tx, without waiting for its acceptance")
 	cmd.Flags().Uint16Var(&delegationFee, "delegation-fee", 100, "(PoS only) delegation fee (in bips)")
+	cmd.Flags().StringVar(&subnetIDstr, "subnet-id", "", "subnet ID (only if blockchain name is not provided)")
+	cmd.Flags().StringVar(&validatorManagerOwnerAddress, "validator-manager-owner", "", "validator manager owner address (only if blockchain name is not provided)")
+	cmd.Flags().Uint64Var(&weight, validatorWeightFlag, uint64(constants.DefaultStakeWeight), "set the weight of the validator")


Have we considered refactoring the input validation to be on the flags rather than in the commands?

Similarly, have we considered reusing these flag definitions across all commands rather than defining them in each cmd file?

addressed above, ya this is a tech debt.

For values that have many possible input flags, we have made partial work.
We have for example contract.ChainSpec struct that has methods to validate
itself and to automatically add flags to a command. Same with contract.PrivateKeyFlags.
We also have a function for the network model, on networkoptions.AddNetworkFlagsToCmd.
We may want to unify and expand on this pattern, and also apply to some remaining multiple
flags value, like p-chain input key.

We also have made partial work on avoiding using global variables for command flags.
Best of the worlds IMO is to have each command have its unique flags struct.
Example eg cmd/interchain/messengercmd/deploy.go
Why is that? To avoid interference on default flag value initialization between different
commands (each command make its own default value initialization and we had cases
where one command overwrote the default flag value of another one). And to avoid depending
on global variables among different methods which also introduces secondary effects from time
to time. Finally, this simplifies and cleans calling command from another commands.
We need some code standard here.

learyce · 2025-02-25T20:25:53Z

pkg/contract/contract.go

@@ -630,3 +630,24 @@ func UnpackLog(
 	contract := bind.NewBoundContract(common.Address{}, *abi, nil, nil, nil)
 	return contract.UnpackLog(event, eventName, log)
 }
+
+// GetContractOwner gets owner for https://docs.openzeppelin.com/contracts/2.x/api/ownership#Ownable-owner contracts
+func GetContractOwner(


What is this used for? And what determines which contract addresses we call this on?

This is to see who can make changes to a PoA L1 since only the holder of the private key to validator manager controller address can make changes like add and remove validator. Since validator manager contracts are openzeppelin contracts we can use https://docs.openzeppelin.com/contracts/2.x/api/ownership#Ownable-owner to see which address is controlling the validator manager contract.

learyce · 2025-02-25T20:26:59Z

cmd/blockchaincmd/add_validator.go

-	sc, err := app.LoadSidecar(blockchainName)
-	if err != nil {
-		return fmt.Errorf("failed to load sidecar: %w", err)
+func addValidator(cmd *cobra.Command, args []string) error {


Do we have any unite tests + e2e tests defined on this?

no unit test as of now for remote validators. To test this, we will have to simulate local network, create an L1 on top of it (using ANR to use local machine for bootstrap validators) and create another validator to add (using local machine to create another instance of validator). This means that we have to create two separate processes of local machine validators, which we can't do currently.

It's on backlog to do once TMPnet is implement for local machine clusters

add validator on remote l1

fd813de

sukantoraymond requested a review from a team as a code owner February 14, 2025 18:48

sukantoraymond requested a review from meaghanfitzgerald February 14, 2025 18:48

sukantoraymond marked this pull request as draft February 14, 2025 18:49

github-actions bot assigned sukantoraymond Feb 14, 2025

sukantoraymond added this to the L1 Validator Management milestone Feb 17, 2025

sukantoraymond added 6 commits February 17, 2025 20:24

fix error

84f8196

remove print

62ca8d1

Merge branch 'main' into add-validator-remote-l1

90f1ae1

fix error

a57ad9e

get validator manager owner

929f620

check if poa

7de4e3f

sukantoraymond marked this pull request as ready for review February 20, 2025 18:05

sukantoraymond added 13 commits February 20, 2025 13:14

fix test

afed4c0

remove print

044b877

fmt

2f511be

lint

4639e58

Merge branch 'main' into add-validator-remote-l1

ee7df72

revert change

e502b7d

fix lint

6770c15

fixes

b737623

update wait time

1c86b21

lint

18af22b

Merge branch 'main' into add-validator-remote-l1

670a51f

Signed-off-by: sukantoraymond <[email protected]>

fix merge

e95c6a7

Merge branch 'main' into add-validator-remote-l1

66263c1

Signed-off-by: sukantoraymond <[email protected]>

felipemadero reviewed Feb 24, 2025

View reviewed changes

sukantoraymond added 3 commits February 24, 2025 18:35

Merge branch 'main' into add-validator-remote-l1

5c7cf59

address comments

ee40c92

lint

d6a2674

learyce reviewed Feb 25, 2025

View reviewed changes

cmd/blockchaincmd/add_validator.go Show resolved Hide resolved

learyce reviewed Feb 25, 2025

View reviewed changes

sukantoraymond added 3 commits February 25, 2025 19:46

address comments

6ecef06

address comments

86093cb

lint

52b3e02

felipemadero approved these changes Feb 26, 2025

View reviewed changes

sukantoraymond added 3 commits February 26, 2025 18:12

Merge branch 'main' into add-validator-remote-l1

97c4b96

use warp to get blockchain

e6dfab7

lint

149d8f4

sukantoraymond merged commit 4bf7b88 into main Feb 27, 2025
36 of 37 checks passed

sukantoraymond deleted the add-validator-remote-l1 branch February 27, 2025 00:03

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add Validator for remote L1 without importing blockchain #2607

Add Validator for remote L1 without importing blockchain #2607

sukantoraymond commented Feb 14, 2025 •

edited

Loading

felipemadero Feb 24, 2025

sukantoraymond Feb 25, 2025 •

edited

Loading

felipemadero Feb 25, 2025

sukantoraymond Feb 26, 2025

felipemadero Feb 26, 2025 •

edited

Loading

felipemadero Feb 24, 2025

felipemadero Feb 24, 2025

felipemadero Feb 24, 2025

felipemadero Feb 24, 2025

sukantoraymond Feb 25, 2025

felipemadero Feb 25, 2025

felipemadero Feb 25, 2025

felipemadero Feb 25, 2025

sukantoraymond Feb 26, 2025

learyce Feb 25, 2025

sukantoraymond Feb 26, 2025

felipemadero Feb 26, 2025 •

edited

Loading

learyce Feb 25, 2025

sukantoraymond Feb 26, 2025

felipemadero Feb 26, 2025

felipemadero Feb 26, 2025 •

edited

Loading

learyce Feb 25, 2025

sukantoraymond Feb 26, 2025

learyce Feb 25, 2025

sukantoraymond Feb 26, 2025 •

edited

Loading

sukantoraymond Feb 26, 2025

Add Validator for remote L1 without importing blockchain #2607

Add Validator for remote L1 without importing blockchain #2607

Conversation

sukantoraymond commented Feb 14, 2025 • edited Loading

Choose a reason for hiding this comment

sukantoraymond Feb 25, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

felipemadero Feb 26, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

felipemadero Feb 26, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

felipemadero Feb 26, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sukantoraymond Feb 26, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sukantoraymond commented Feb 14, 2025 •

edited

Loading

sukantoraymond Feb 25, 2025 •

edited

Loading

felipemadero Feb 26, 2025 •

edited

Loading

felipemadero Feb 26, 2025 •

edited

Loading

felipemadero Feb 26, 2025 •

edited

Loading

sukantoraymond Feb 26, 2025 •

edited

Loading