ARC-41: Non-Custodial Validator Activation

[lukenewman]

---

arc: 0041
title: Non-Custodial Validator Activation
authors: [email protected]
discussion: #73
topic: Protocol
status: Draft
created: 05/01/2024

Abstract

For a validator to be activated (added to the committee), it must have a bond of at least 10,000,000 (10M) credits to its address. Currently, the only way for this to happen is for the funds to be custodied and bonded by the validator's keys. This is a problem for initial validator delegators that don't want to sacrifice custody of their funds. For example, for the Aleo Network Foundation or any main investors to bond credits and activate the initial set of validators, they would currently have to do one of the following:

• fund and bond with the private key and then send this key to the validator
• fund the validator's private key and then trust that the validator bonds these credits with the desired withdrawal address.

Both of these options are not ideal.

This proposal introduces a new function to credits.aleo that would allow a delegator to activate a validator with an initial bond of 10M credits without having to sacrifice custody of their funds.

Specification

credits.aleo/activate_validator

A new function needs to be added to credits.aleo that allows a validator to be added to the committee and its initial stake of 10M credits to come from a different address. This initial draft of the logic is grafted from the validator logic in bond_public.

function activate_validator:
    // Input the validator's address.
    input r0 as address.public;
    // Input the withdrawal address.
    input r1 as address.public;
    // Input the amount of microcredits to bond.
    input r2 as u64.public;

    // Determine if the amount is at least 10 million credits.
    gte r2 10_000_000_000u64 into r3;
    // Enforce the amount is at least 10 million credits.
    assert.eq r3 true;

    // Bond the specified amount of microcredits to the specified validator.
    async bond_public self.caller r0 r1 r2 into r4;
    // Output the finalize future.
    output r4 as credits.aleo/bond_public.future;

finalize activate_validator:
    // Input the staker's address.
    input r0 as address.public;
    // Input the validator's address.
    input r1 as address.public;
    // Input the withdrawal address.
    input r2 as address.public;
    // Input the amount of microcredits to bond.
    input r3 as u64.public;

    /* Committee */

    // Check if the validator is already in the committee.
    contains committee[r1] into r6;
    // Ensure the validator is not already in the committee.
    assert.eq r6 false;

    // Get the committee size.
    get.or_use metadata[aleo1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq3ljyzc] 0u32 into r7;
    // Increment the committee size by one.
    add r7 1u32 into r8;
    // Determine if the committee size is less than or equal to 10.
    lte r8 10u32 into r9;
    // Enforce that the committee size is less than or equal to 10.
    assert.eq r9 true;
    // Set the new committee size.
    set r8 into metadata[aleo1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq3ljyzc];
    // Set the withdrawal address for the validator.
    set r2 into withdraw[r1];

    // Construct the initial committee state.
    // Note: We set the initial 'is_open' state to 'true'.
    cast 0u64 true into r10 as committee_state;
    // Retrieve the committee state of the specified validator.
    get.or_use committee[r1] r10 into r11;
    // Ensure that the validator is open to stakers.
    assert.eq r11.is_open true;

    // Increment the stake for the specified validator.
    add r11.microcredits r3 into r12;
    // Construct the updated committee state.
    cast r12 r11.is_open into r13 as committee_state;

    /* Bonded */

    // Construct the initial bond state.
    cast r1 0u64 into r14 as bond_state;
    // Get the bond state for the caller, or default to the initial bond state.
    get.or_use bonded[r1] r14 into r15;
    // Enforce the validator matches in the bond state.
    assert.eq r15.validator r1;

    // Increment the microcredits in the bond state.
    add r11.microcredits r3 into r16;
    // Determine if the amount is at least 10 million credits.
    gte r16 10_000_000_000_000u64 into r17;
    // Enforce the amount is at least 10 million credits.
    assert.eq r17 true;

    // Construct the updated bond state.
    cast r1 r16 into r18 as bond_state;

    /* Account */

    // Get the balance of the caller.
    // If the account does not exist, this finalize scope will fail.
    get account[r0] into r19;
    // Decrement the balance of the caller.
    sub r19 r3 into r20;

    /* Writes */

    // Update the committee state of the specified validator.
    set r13 into committee[r1];
    // Update the bond state for the caller.
    set r18 into bonded[r0]; // or should this be bonded[r1] to update the bond state of the specified validator
    // Update the balance of the caller.
    set r20 into account[r0];

Test Cases

We will both manually test and also amend test_credits.rs to have the following test cases:

• an account ("funder") with 10M credits should be able to activate another address as a validator without having the other address ever custody the funds
• the funder should be able to specify a withdrawal address like in ARC-37
• the validator should be able to have full control over unbonding, and if it does unbond below the 10M credit threshold, the entire stake should be returned to the withdrawal address specified by the funder

Dependencies

None

Backwards Compatibility

Not necessary.

Security & Compliance

credits.aleo will require another audit.

This proposal opens up the possibility of a delegator pool, ARC38-esque program activating a new validator. There will be a subsequent ARC that outlines this possibility.

References

• credits.aleo source
• test_credits.rs source

[jk-apybara]

This proposal opens up the possibility of a delegator pool, ARC38-esque program activating a new validator.

Is there a reason to keep this possibility out of scope of this ARC? This seems critical. With the current spec, the foundation and a few major investors will be the only entities able to activate validators.