ARC-0037: Validator Node, Separation of Owner Address and Worker Address

[OzielLa]

---

arc: ARC-0037
title: Validator Node, Separation of Owner Address and Worker Address
authors: OzielLa
topic: Protocol
status: Draft
created: 11/16/2023

Abstract

The validator address holds a significant amount of credits and requires real-time proof verification work, which imposes a significant security burden on the validator. To address this, a worker address is added to specifically handle real-time proof verification tasks. The validator address is responsible for managing the worker.

Specification

• Add a extra field in credits.aleo/struct committee_state

// The `committee_state` struct tracks the total stake of the validator, and whether they are open to stakers.
struct committee_state:
    // The worker address is specified by the validator node for performing proof verification work, defaulting to the validator address.
    worker as address;
    // The amount of microcredits bonded to the validator, by the validator and its delegators.
    microcredits as u64;
    // The boolean flag indicating if the validator is open to stakers.
    is_open as boolean;

• Modify the worker address using credits.aleo/setworker

function set_worker:
	input r0 as address.public;
	async set_worker self.caller r0;

finalize set_worker:
  input r0 as address.public;
	input r1 as address.public;
	// todo Assert r0 is the validator address
	// todo Modify the worker in committee_state to r1

Test Cases

 leo run set_worker aleo1cdqm8jc3cusuqeunecxh9p76lu3zfzjn2hq2lwxdzad490jzwqyqvv2k7n

Reference Implementations

Dependencies

Backwards Compatibility

Security & Compliance

References

[marco-storswift]

I think this proposal is very useful because it can solve the problem of asset security for Validators, referring to ETH and FIL have similar practices

[OzielLa]

In the current proof verification process, it is required that the number of certificates submitted by validators exceeds a specified threshold. However, when running a validator, I need to sign with an account that has staked over 1 million Aleo. This is considered risky. Therefore, this proposal aims to modify the BatchHeader by separating the "author" into "owner" and "worker."

Owner: Holds ownership of the validator and has the authority to modify the worker.

Worker: Responsible for issuing certificates and handling the actual verification work.

Through this separation, the owner can run the validator more securely without the need to sign with an account staking a significant amount of Aleo.

batch-header

• BatchHeader add worker: Address<N>,

pub struct BatchHeader<N: Network> {
    /// The batch ID, defined as the hash of the round number, timestamp, transmission IDs, and previous batch certificate IDs.
    batch_id: Field<N>,
    /// The of the batch.
    author: Address<N>,
    /// The worker of validator.
    worker: Address<N>,
    /// The round number.
    round: u64,
    /// The timestamp.
    timestamp: i64,
    /// The set of `transmission IDs`.
    transmission_ids: IndexSet<TransmissionID<N>>,
    /// The batch certificate IDs of the previous round.
    previous_certificate_ids: IndexSet<Field<N>>,
    /// The signature of the batch ID from the creator.
    signature: Signature<N>,
}

• Function new

pub fn new<R: Rng + CryptoRng>(
        owner: Address<N>,
        private_key: &PrivateKey<N>,
        round: u64,
        timestamp: i64,
        transmission_ids: IndexSet<TransmissionID<N>>,
        previous_certificate_ids: IndexSet<Field<N>>,
        rng: &mut R,
    ) -> Result<Self> {
        match round {
            // If the round is zero or one, then there should be no previous certificate IDs.
            0 | 1 => ensure!(previous_certificate_ids.is_empty(), "Invalid round number, must not have certificates"),
            // If the round is not zero and not one, then there should be at least one previous certificate ID.
            _ => ensure!(!previous_certificate_ids.is_empty(), "Invalid round number, must have certificates"),
        }
        // Retrieve the address.
        let author = owner;
        // Retrieve the address.
        let worker = Address::try_from(private_key)?;
        // Compute the batch ID.
        let batch_id = Self::compute_batch_id(author, round, timestamp, &transmission_ids, &previous_certificate_ids)?;
        // Sign the preimage.
        let signature = private_key.sign(&[batch_id], rng)?;
        // Return the batch header.
        Ok(Self { author, worker, batch_id, round, timestamp, transmission_ids, previous_certificate_ids, signature })
    }

• Function from

pub fn from(
        author: Address<N>,
        worker: Address<N>,
        round: u64,
        timestamp: i64,
        transmission_ids: IndexSet<TransmissionID<N>>,
        previous_certificate_ids: IndexSet<Field<N>>,
        signature: Signature<N>,
    ) -> Result<Self> {
        match round {
            // If the round is zero or one, then there should be no previous certificate IDs.
            0 | 1 => ensure!(previous_certificate_ids.is_empty(), "Invalid round number, must not have certificates"),
            // If the round is not zero and not one, then there should be at least one previous certificate ID.
            _ => ensure!(!previous_certificate_ids.is_empty(), "Invalid round number, must have certificates"),
        }
        // Compute the batch ID.
        let batch_id = Self::compute_batch_id(author, round, timestamp, &transmission_ids, &previous_certificate_ids)?;
        // Verify the signature.
        if !signature.verify(&worker, &[batch_id]) {
            bail!("Invalid signature for the batch header");
        }
        // Return the batch header.
        Ok(Self { author, worker, batch_id, round, timestamp, transmission_ids, previous_certificate_ids, signature })
    }

• Function read_le, write_le,serialize,deserialize

[jwelrynewone]

From my perspective, it is essential to separate a worker from a validator. Combined running validator and worker requires huge computation and division worker/validator would decrease its centralization and would reduce the impact of possible malicious behavior.

[swift-mx]

A simple implementation https://github.com/AleoHQ/snarkVM/pull/2185

[LeoYsd]

This is a very useful proposal

[Delaw258]

useful but how can i become a validator

[johnchenyan]

Expect the proposal to be incorporated into the mainnet

[d0cd]

This proposal, while improving the security posture of a validator, introduces non-trivial changes to the protocol including functional and storage overhead.

Instead, consider the alternate design:

• On bond_public the staker (validator or delegator) specifies a withdrawal address. It can either be the staker’s own address or a “cold” address.
• Once set, the withdrawal address cannot be updated.
• On calling unbond_* the funds are allocated to the withdrawal address. Even if the stakers’s key (the “hot” key in the case of the validator) is compromised, the funds can only be sent to the withdrawal address.

@OzielLa what do you think?

[OzielLa]

Oh, it would be better to add the withdrawal address to the committee_map instead. This approach would reduce the overall data size. Additionally, since the delegator itself is not involved in the operations, it is not recommended to add a withdrawal address for it as well.

[swift-mx]

This is a minimal modification implementation https://github.com/AleoHQ/snarkVM/pull/2366.

1. Provide a method for setting the withdraw address.
2. When claiming unbond_public, give the credits from unbonding to the withdraw address

[raychu86]

Thanks for your implementation! One problem I see with the naive approach is that if the "hot" address is compromised in any way, then the malicious party could change the withdraw address to any arbitrary address controlled by the attacker and withdraw from there.

I believe this withdraw address should be immutable or have some sort of time-lock(?) to allow the validators to detect any undesired change and secure the stake before the attacker does.

[mx819812523]

Thanks for your suggestion , It has been verified here that withdrawals can only be set once. The latest code has been updated #2366

[Jackytan2018]

Sounds grate !

[Jackytan2018]

On my point of view, it’s better to have two keys: one for working, such as vote, message signature, the other one for owner , can withdraw token. This is a practical solution in Filecoin.

What's more, like ETH2.0, there are also two keys for validators: one is verifing key, used to verify the messages and produce block. the other one is withdrawing key, used to receive block rewards and transfer tokens.

In this way, the validator's assets will be more secure.

[d0cd]

@Jackytan2018 I believe that's what the alternate proposal above accomplishes. Are you in agreement?

[Jackytan2018]

yeh, i see your idea, i think it's better to add a withraw address ( same as eth2.0). This way maybe easier to implement.

[raychu86]

I've implemented the change with the withdrawal address approach here - https://github.com/AleoHQ/snarkVM/pull/2385.

More details are explained in the PR description, but TLDR -

1. Withdrawal addresses must be specified when the staker bonds credits.
2. Withdrawal addresses can't be changed until the staker is completely unbonded (and unbonded stake is claimed).
3. Withdrawal addresses receive all the unbonded stake.

[OzielLa]

Awesome! One suggestion, it will be great if a confirming process enhanced on withdrawal_address for bond_public to avoid any mistake possibilities, because the withdrawal_address takes over control the gains of staking assets.