# \[Proposal\] PERCH: Protocol Evaluation and Request Coordination Hub **URL:** \ **Category:** General\ **Created:** [September 6, 2024, 12:25pm UTC](https://research.lido.fi/t/proposal-perch-protocol-evaluation-and-request-coordination-hub/8306 "2024-09-06T12:25:26Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![Perrier](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/perrier/32/3366_2.png) [@Perrier](https://research.lido.fi/u/Perrier)\ **Post date:** [September 6, 2024, 12:25pm UTC](https://research.lido.fi/t/proposal-perch-protocol-evaluation-and-request-coordination-hub/8306/1 "2024-09-06T12:25:26Z")
#### 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. ---
**Author:** ![murat\_preconf.eth](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/murat_preconf.eth/32/4452_2.png) [@murat\_preconf.eth](https://research.lido.fi/u/murat_preconf.eth)\ **Post date:** [September 7, 2024, 9:36pm UTC](https://research.lido.fi/t/proposal-perch-protocol-evaluation-and-request-coordination-hub/8306/2 "2024-09-07T21:36:48Z")
> [@Perrier](#): > > favor a specific set of relayers or builders 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? ---
**Author:** ![Perrier](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/perrier/32/3366_2.png) [@Perrier](https://research.lido.fi/u/Perrier)\ **Post date:** [September 9, 2024, 12:30pm UTC](https://research.lido.fi/t/proposal-perch-protocol-evaluation-and-request-coordination-hub/8306/3 "2024-09-09T12:30:58Z")
Do you mind elaborating on what you mean by availability? @murat_preconf.eth ---
**Author:** ![murat\_preconf.eth](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/murat_preconf.eth/32/4452_2.png) [@murat\_preconf.eth](https://research.lido.fi/u/murat_preconf.eth)\ **Post date:** [September 10, 2024, 12:38am UTC](https://research.lido.fi/t/proposal-perch-protocol-evaluation-and-request-coordination-hub/8306/4 "2024-09-10T00:38:32Z")
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”? ---
**Author:** ![sacha](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/sacha/32/5809_2.png) [@sacha](https://research.lido.fi/u/sacha)\ **Post date:** [September 11, 2024, 12:36pm UTC](https://research.lido.fi/t/proposal-perch-protocol-evaluation-and-request-coordination-hub/8306/5 "2024-09-11T12:36:40Z")
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) ---
**Author:** ![murat\_preconf.eth](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/murat_preconf.eth/32/4452_2.png) [@murat\_preconf.eth](https://research.lido.fi/u/murat_preconf.eth)\ **Post date:** [September 11, 2024, 6:48pm UTC](https://research.lido.fi/t/proposal-perch-protocol-evaluation-and-request-coordination-hub/8306/6 "2024-09-11T18:48:38Z")
That makes a lot of sense - thanks for the clarification! ---
**Author:** ![eric\_bloxroute](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/eric_bloxroute/32/3550_2.png) [@eric\_bloxroute](https://research.lido.fi/u/eric_bloxroute)\ **Post date:** [October 17, 2024, 1:26pm UTC](https://research.lido.fi/t/proposal-perch-protocol-evaluation-and-request-coordination-hub/8306/7 "2024-10-17T13:26:35Z")
Hello, thanks! This is a link to our relay proxy request - posting a reply in this thread as asked: > [@Proposal: BloXroute Relay proxy](https://research.lido.fi/t/proposal-bloxroute-relay-proxy/7870): > > Regarding using BloXroute relay proxies, we made a change to our architecture, where validators don’t need to run any local components, yet can still connect to a relay proxy. We now allow validators to use relay proxies in many regions throughout the world (US, EU, Singapore, Hong Kong, Tokyo, Sydney, and Dublin) without having to run their own. These proxies communicate with the relay using gRPC, and are faster than communicating with the relay directly. Validators using relay proxies receive … ---
**Author:** ![irfanshaik11](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/irfanshaik11/32/5466_2.png) [@irfanshaik11](https://research.lido.fi/u/irfanshaik11)\ **Post date:** [February 5, 2025, 1:25am UTC](https://research.lido.fi/t/proposal-perch-protocol-evaluation-and-request-coordination-hub/8306/8 "2025-02-05T01:25:36Z")
Our team at Interstate is supportive of this initiative, flagging our earlier proposal here: [Introducing Interstate: Decentralized Proposer Commitments](https://research.lido.fi/t/introducing-interstate-decentralized-proposer-commitments/9298) ---
**Author:** ![paulhauner](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/paulhauner/32/1989_2.png) [@paulhauner](https://research.lido.fi/u/paulhauner)\ **Post date:** [February 5, 2025, 6:58pm UTC](https://research.lido.fi/t/proposal-perch-protocol-evaluation-and-request-coordination-hub/8306/9 "2025-02-05T18:58:06Z")
I’m flagging Sigma Prime’s interest in testing Commit-Boost 🫡