ARC-0101 – Requirements and Evaluation Criteria for Validators

[zkxuerb]

Introduction

As the Aleo network grows and matures, ensuring a robust, secure, and equitable validator ecosystem is paramount. This ARC sets forth a proposed standard for validators participating in the Aleo Network, detailing guidelines and evaluation criteria that strive to maintain network reliability, resilience, and fairness. These guidelines have been developed in close collaboration between the Aleo Network Foundation (ANF) and the Aleo community, drawing on insights gained from ongoing network operations and community feedback.

The purpose of this ARC is to establish transparent, measurable requirements and encourage a merit-based validator selection and evaluation process. By adhering to these guidelines, validators can help safeguard the network’s long-term stability and align with Aleo’s mission of fostering a decentralised and secure ecosystem.

Validator Requirements Guideline

1. Performance Requirements

• Network Uptime: Validators must maintain a high level of availability. Extended downtime should not exceed 12 hours.
• Node Maintenance: Validators must maintain Canary, Testnet and Mainnet validator nodes and 3 client nodes.
• Monitoring Metrics: Validators must regularly submit both Testnet and Mainnet validator metrics for ongoing assessment of performance and reliability.
• Consensus Liveliness & Recovery: Validators must actively participate in consensus and promptly recover if disconnected, ensuring the continuity and correctness of the ledger.
• Client Synchronization: Validators must successfully complete required synchronization tests following network upgrades to confirm the network’s operational readiness within 24 hours of announcement.

2. Security Requirements

• Penetration Testing & Security Audits: Validators must conduct and furnish results of regular penetration tests and security audits, at a minimum on an annual basis or as requested by the ANF.
• Failover & Infrastructure Resilience: Validators must maintain robust security measures, including backup nodes, monitoring and alerting systems, firewalls, and secure key management solutions to mitigate risks and safeguard network integrity.

3. Tokenomics Requirements

• Stake Limitations:
  • Validators must not exceed 25% of the total network stake.
  • Validators must maintain a minimum stake of 10,000,000 Aleo Credits (or the current minimum stake) to remain active.

4. Hardware Requirements

• Minimum Specifications: Validators must meet or exceed hardware parameters set by the ANF, including:
  • CPU: 64 cores (128 cores or more preferred)
  • RAM: 256GiB (384GiB or more preferred)
  • Storage: 4TB (6TB or more preferred)
  • Network: 500Mbps minimum upload/download bandwidth

5. Participation Requirements

• Maintenance & Support: Validators must respond to requests for upgrades within 24 hours and complete such upgrades within the specified timeframe. They must also remain responsive (within 24 hours) for urgent network issues and coordination events.
• Node Operations: Participation in Canary, Testnet, Mainnet node and Mainnet Client node operations is required to ensure ongoing network quality.
• Governance & Community Engagement: Validators must participate in at least 80% of governance votes and regularly attend coordination calls. Missing more than 15% of the calls in any quarter without prior notice is considered a violation of these guidelines.

Validator Evaluation Criteria for Foundation Delegation

The ANF will periodically evaluate validators based on the following criteria. Each category carries weight and contributes to the overall assessment of a validator’s contributions and reliability:

1. Validator operation requirements (as outlined above)

2. Technical Contribution
   Open-source code contributions to Aleo network.
   Development or maintenance of validator tools. (e.g., Dashboards, Documentation, Guides).
   Operation of reliable RPC endpoints and similar infrastructure services.

3. Ecosystem Contribution
   Development and deployment of dApps on the Aleo ecosystem.
   Creation and distribution of educational content, tutorials, and community materials.
   Hosting or contributing to events (workshops, meetups) that grow the community and developer base.

4. Participation & Communication
   Timely and clear communication with the ANF and community.
   Participation in governance discussions and responsiveness to critical network updates.

5. Strategic Importance
   Geographic diversity to ensure a globally distributed and resilient validator set.
   Engagement with local ecosystems, key market players, and community builders.
   Business development efforts that foster ecosystem partnerships and network growth.

6. Long-Term Collaborations (Vendors, Partners, Grantees)
   Participation in events and marketing initiatives that promote the Aleo network.
   Demonstrated long-term commitment to ecosystem development and improvement.

7. Governance
   Active voting behaviour and thoughtful input on governance proposals.
   Constructive participation in community decision-making processes.

Conclusion

By setting forth these guidelines and evaluation criteria, we aim to strengthen the Aleo validator community, ensuring that participants meet the highest standards of performance, security, fairness, and ecosystem engagement. This ARC serves as a foundational reference for validators, the ANF, and the community, facilitating transparent evaluation and ongoing improvement of the Aleo network.

We invite feedback and comments on this ARC from the Aleo community. Your insights, questions, and suggestions will help refine these guidelines and ensure they serve the best interests of the network and its participants. Together, we will continue to build a secure, inclusive, and sustainable Aleo ecosystem.

[everstakemasha]

Thank you, @zkxuerb, for drafting this thoughtful and well-rounded proposal. I completely agree that having clear expectations for validator responsibilities is essential for maintaining a strong and accountable community.

That said, I noticed a detail regarding the bi-weekly call schedule. Since calls aren’t held weekly, missing just one call in a quarter could already exceed the 15% threshold. It might make sense to adjust this requirement to better reflect the current frequency of calls.

Thanks again for your effort on this - it’s a great step toward ensuring consistency and engagement.

[pa-long]

Alternatively, the requirement could be to have attended to at least m calls among the last n calls.

[zkxuerb]

Yes I have changed it to not specify a frequency for the coordination call.

[steven004]

Missing more than 15% of the calls in any quarter without prior notice is considered a violation of these guidelines.

Given the condition "without prior notice", I agree this is not an overly strict requirement. I would suggest that anyone unable to attend a meeting should notify the team in advance. Additionally, it would be helpful if they could provide comments or input on the meeting agenda or context beforehand.

[asharma13524]

Thanks for putting the proposal together. Generally in agreement with the proposal. I wanted to ask about validator and client minimum required specs and how we're thinking about these.

Is there room to reduce these specs in order to improve validator unit economics? There had been some prior discussion around reducing minimum specs, and I believe some of the work in resolving bottlenecks such as client sync slowness have been successfully merged.

See below a few references.

ProvableHQ/snarkOS#3358
ProvableHQ/snarkVM#2564 (see safety section in pr description)

[vicsn]

Agreed, reducing costs should be a big priority!

I suspect there will be room for a reduction in validator specs in Q1.

Once this PR is revived, memory requirements can go down significantly: ProvableHQ/snarkVM#2519

CPU requirements can likely also go down at current validator size. Happy to pick this up in Q1 or comment on other's benchmarks!

[ertemann]

Most costs are probably more in needing 3 duplicate setups for all network types rather than the hardware itself though. If validator sustainability ever becomes top of mind then that redundant network setup forced for all validators is probably the first thing that would have to go.

For now its perfectly manageable though.

[ertemann]

Thank you for the proposal.

In our opinion it is concise, gets the point accross for what the foundation deems important and sets high but perfectly reasonable standards for operators on the network.

There is one point I would like to provide some context on though because I deem it infeasible to enforce or request, especially as the operator set grows and gets a more diverse set of companies and actors onboard.

Validators must conduct and furnish results of regular penetration tests and security audits, at a minimum on an annual basis or as requested by the ANF.

speaking for ourselves we would not be able to do this either annually or on request at the current stage of our company (atleast not for all of our infrastructure over the many networks we serve), and that is just speaking from experience. Security audits are mainly not applicable to operators that do not leverage smart contracts or pooling solutions but penetration tests most definitely are. We understand having these tests done is an important show of faith to the foundation and overall network but they are expensive both time and money wise and require a very mature business and documentation setup that is not necessarily available at most of the midsize and smaller proof-of-stake operators. In our case we have done many internal pentests and requested pricing and setup for external ones as well, but they do not occur on a regular cadence and it would be hard for us to plan them before we finish our ISO and other standardization reports (which again are largely unapplicable to validation). We are happy to get a timeline and perform another pentest before that date but want to be honest that this requirement will be harder and harder to fulfill the more the network will onboard small and medium size operators. Maybe specifying that these tests and audits only apply to the Aleo part of the infrastructure would make this request more feasible.

Besides this, requesting a set of contributions from operators to show their continued alignment is very much in-line with our best-practices and we are looking forward to the next evaluation period.