[Proposal] PERCH: Protocol Evaluation and Request Coordination Hub

Overview

The proposal is addressed at projects/protocols that provide functions, i.e relays, credible commitments…, and who are seeking operators running validators on Lido on Ethereum to test/utilize these functions.

It’s also addressed at Node Operators (NOs), running validators on Lido on Ethereum, who wish to express their interest in participating in collaborative testing on test networks. The objective is to conduct tests that could potentially enhance the resilience and performance of Ethereum, provided these tests do not disrupt the proper functioning of the Lido protocol.

In sum, the Protocol Evaluation and Request Coordination Hub (PERCH) framework proposes a collaborative structure for protocols and projects seeking participation from node operators (NOs) running validators on Lido on Ethereum. This framework facilitates the evaluation and testing of various research technologies—such as relays, credible commitments, blob propagation, and more—by coordinating participation between protocol developers and node operators. The goal is to conduct thorough tests that enhance the resilience and performance of Ethereum, ensuring that these tests do not disrupt the proper functioning of any ongoing ecosystem protocols, such as those within the Lido context.

Expectations

For Applicants (projects and protocols):

  1. Number of Participants: Specify the ideal number of operators/validators required.
  2. Application Form: Attach a form for NOs to express interest (if relevant) and provide the necessary details. Additional instructions attached below in the How to Participate section
  3. Testing Outline:
  • Software and/or protocols to be used.
  • Networks on which the tests will be conducted (e.g., Holesky or others).
  • Duration of the testing period.
  • Expected impact on the network as a result of these tests.
  1. Requirements:
    Any project or protocol undergoing a testnet with Node Operators (NOs) should, at a minimum, meet the following requirements:
  • Alignment with Ethereum Roadmap: The proposed technology should complement and advance Ethereum’s long-term goals, particularly in areas such as scaling, censorship resistance, or decentralization. Solutions should have a clear path to potentially becoming native to the protocol, aligning with Ethereum’s future upgrades and developments
  • Neutrality and Inclusivity: The technology should enhance the user experience and robustness of the Ethereum network without introducing favoritism or reliance on specific service providers. For instance, it should not require the Lido protocol to favor a specific set of relayers or builders
  • Adherence to Community Standards: The technology should be in line with broader Ethereum community efforts, aiming for interoperability and alignment with other proposals. For example, credible commitments and relays should respect ongoing discussions on standardization and security best practices.
  • Security Best Practices: All technologies and protocols must adhere to the highest standards of smart contract security. This includes regular code reviews, third-party audits, and formal verification where applicable. Developers should ensure that all known vulnerabilities are addressed prior to deployment in any testnet environment.
  • Complementary Use Cases: Proposed technologies should add value to existing use cases and not inhibit the growth or adoption of other innovations. For instance, the pre-confirmation use case does not crowd out the inclusion list use case

For Node Operators

  1. Network Information:
  • Specify the network (e.g., Holesky or others) where the tests will be conducted.
  • Detail the subset of your validators participating in the tests.
  • Duration of the testing period.
  1. Post-Testing Assessment:
  • Provide a brief report on the results of the tests.
  • Engage the community in follow-up discussions based on the outcomes.

Motivation

The PERCH framework emerges from the recognition of the need for a structured process to coordinate testnet participation between protocol developers and node operators. For example, Titan has developed infrastructure to optimize blob propagation by decoupling payloads from headers, reducing latency for rollups. As they prepare to test asynchronous blob propagation on the Holesky test network, this proposal establishes a minimally viable process for similar future requests, streamlining testing, and fostering continuous improvement within the community.

Rather than making isolated proposals for each testing initiative, we propose establishing a minimally viable process for handling similar requests in the future. This approach aims to streamline testing and foster ongoing improvements within the community.

We invite all interested parties to participate in this collaborative effort. Your involvement will contribute significantly to the robustness and advancement of the Ethereum ecosystem.

How to Participate

For Applicants (Projects and Protocols):

If you are interested in participating, please create a new thread in the research forum under the Department of Decentralisation tag. Your post should follow the format outlined above, including details such as the number of participants, testing outline, and expected network impact. This will provide visibility for node operators and allow them to review and express interest in collaborating on your proposal.

For Node Operators (NOs):

After reviewing an applicant’s post, please respond directly in the relevant thread, indicating your interest and any details about the subset of your validators participating in the testing. Once the testnet phase is complete, please share a post-testnet assessment in the same thread, including outcomes, insights, and any follow-up actions as outlined in the expectations above.

Thank you for your interest and collaboration. For any questions or further clarification, feel free to reach out to us on this forum.

9 Likes

Thanks for this proposal - very helpful to think of a framework for coordination for new projects. How do you suggest projects balance Neutrality and Inclusivity with Availability? Testing early projects often requires integration by service providers, which can take varying times between them. Is this meant for projects to be committed to Neutrality and Inclusivity by design or be supported by every service provider at the moment of application?

2 Likes

Do you mind elaborating on what you mean by availability? @murat_preconf.eth

Definitely; service providers move on different timelines, so if a solution is compatible with all would it have to wait to meet the criteria until it’s available by every provider? Or is it a check for favoring, where protocols rules enforce “you can use A but not B”?

not sure i understand the concern. the main idea here is to encourage rapid (and reversible) experimentation on testnets in a way that does not harm the protocol, enforce exclusivity, or compromise mainnet neutrality

as i see it, a necessary – but not sufficient – condition here is the option to start seamlessly testing with a subset of interested operators and providers, and to scale if/when it becomes possible (if this is required)

2 Likes

That makes a lot of sense - thanks for the clarification!

2 Likes

Hello, thanks!
This is a link to our relay proxy request - posting a reply in this thread as asked: