TL;DR

This a proposal to fund Nethermind to design white-labeling resistance mechanism. The delivery will include a detailed discussion of the final design and a systematization of knowledge for white-labeling prevention, oracle systems, prediction markets, and token-curated assets. During the project, a team will investigate what the state-of-the-art is, what solutions are or will be used in practice, and how. Then we will propose concrete mechanisms to make Lido’s network white-labeling resistant. The project will be one of the steps toward enabling Lido to onboard new operators in a permissionless manner. This is a continuation of the previous proposal. The project will take 22 weeks, and its cost — 450 000 DAI — will be covered by Lido DAO.

Proposer and work mindset

Proposer

Michał Zając on behalf of Nethermind.

About Nethermind

Nethermind is a team of world-class builders and researchers with expertise across several domains: Ethereum Protocol Engineering, Cryptography Research, Layer-2s, Decentralized Finance (DeFi), Miner Extractable Value (MEV), Smart Contract Development, Security Auditing, and Formal Verification, among others.

Our Research team comprises computer scientists, mathematicians and engineers who work on analyzing, breaking, and designing blockchain and cryptographic schemes. Our expertise and interests span the fields of zero-knowledge proofs, non-deterministic programming, Distributed Validator Technology, and decentralized identity.

Working to solve some of the most challenging problems in the blockchain space, we frequently collaborate with renowned companies and DAOs, such as Ethereum Foundation, StarkWare, Lido Finance, Gnosis Chain, Aave, Flashbots, xDai, Open Zeppelin, Forta Protocol, Energy Web, POA Network and many more. We actively contribute to Ethereum core research and development, EIPs, and network upgrades with the Ethereum Foundation and other client teams.

General work mindset

The following principles will drive the development of the protocols:

• All the design considerations and risk analysis will be done with the consent of the Lido DAO.
• All proposed solutions will come with security analysis. When available, the protocols’ security will be proven.
• Milestones and deliverables will be small to ensure a good overview of the team’s progress.

Ideal mechanism overview

An ideal mechanism evaluates Lido’s DAO validator set according to the operator & validator set strategy described in this note by Lido. More precisely, the mechanism must have methods for improving the validator set if there is an option to do so. It must have zero input from permissioned roles (i.e., no admins/committees). Furthermore, it must have an input of low to zero impact from LDO, stETH, and ETH token holders.

General objectives

We will assist Lido in creating and maintaining a permissionless and high-quality validator set mechanism. This entails:

1. Designing and implementing methods to ensure that validators are run by a high-quality set of operators. In particular, each operator performs its duties on its own and does not cede them to an external party (i.e., it does not hire a white-label operator), nor is secretly associated with other operators, and ensures that its hardware and software run performantly.
2. Conducting a thorough economic analysis to understand how the market fluctuations, or changes in the Ethereum protocol itself, can compromise the system’s security.

The project will be divided into following phases:

• Phase 1: We survey the literature and state-of-the-art approaches to identity and attestation schemes. This phase has been completed already.
• Phase 2: During this phase, we will survey the literature and state-of-the-art approaches to white-labeling-protection. We will focus on arbiter protocols: oracles and prediction markets, to assess they usability in this problem. Then we will propose a mechanism that utilize an arbiter protocol to fight white-labeling. We will also investigate how to disincentivize using white labeling operators. The present proposal focuses solely on this phase.
• Phase 2.5: We will make a proof-of-concept implementation for the white-labeling prevention mechanism designed in Phase 2.
• Phase 3: During this phase we will work on the Sybil resistance. We will prepare a survey on the state-of-the-art approaches and propose a mechanism that significantly increases the cost of creating Sybils.
• Phase 3.5 We will make a proof-of-concept implementation for the Sybil prevention mechanism designed in Phase 3.
• Phase 4: Next, we will proceed to design solutions for assuring a good quality set of operators and economic security of the protocol. We will also describe the resources required to implement the solutions proposed in Phases 1 to 4.
• Phase 5: This phase is mainly concerned with implementing the solutions designed during the previous phases. We will also research some extra topics and problems, as done in the previous phases, and afterward, we will implement them. Further information on this phase will be provided later, by the end of Phase 3.

Project Objective

Phase 2. White-labeling resistance mechanism design

In this part of the project, we will focus on one of the crucial aspects of the security of a permissionless staking protocol. Namely ensuring that operators perform their duties independently and don’t use third parties, so-called white-label operators, to do them on their behalf. An entity that runs multiple operators (whether by controlling Sybils or being a white-label operator) could have too much control over stake, and the protocol in general. This would worsen the overall health of the protocol, weaken its resistance against correlated slashing, and could introduce a single point of failure.

We emphasize that even if we ensure that all onboarding operators are honest, we still need to have a system that detects dishonest parties within the set of already onboarded operators. This is because white-label operators can be created among the onboarded operators, even if these operators honestly entered the system. The latter may happen, e.g., when one entity that runs operators buys another that also runs operators. In that case, the buying party may end up controlling too much of the stake.

Our work plan for developing the white-labeling resistance will begin by researching several techniques that, we believe, have the potential to lead to a solution in isolation or as part of an amalgam. The different types of methods we will explore are listed below. In particular, we will investigate arbiter protocols. The motivation for using arbiter protocols is following — a party that suspects that some operator is a white label could raise that issue and make a corresponding prediction market where people can bet on whether they believe in the claim. Then the conflict would be resolved by an assigned resolution mechanism.

The final goal of our work will be to produce a report explaining exactly how the Lido network can use such methods.

TASK 1 White-labeling resistance. SoK.

We will begin with supplementing the SoK from Phase 1 with an SoK for white-labeling resistance. We will look for such mechanisms used not only in Web3 but also in Web2 and, if necessary, real life.

This part will take 3 weeks.

TASK 2 Arbiter protocols. SoK.

We expect some core components to be decentralized oracles, token-curated assets, and prediction markets (with the focus on the last one). We will use these "arbiter protocols,” as we call them, to assess whether

• a prospective operator will provide good quality services and contribute to the quality of the operators’ set or
• an already onboarded operator uses a white-label operator.

As a first step, we will prepare an SoK for the following topics:

• decentralized oracles
• prediction markets

This part will take 3 weeks.

TASK 3 Arbiter protocols. Resolution mechanisms.

In this part, we will design a mechanism that resolves disputes in arbiter protocols. We will propose concrete setups for decentralized oracles and prediction markets. We will specify which parties make the oracle and who resolves disputes in prediction markets. We will analyze the feasibility of using already onboarded operators as part of an oracle system. Similarly, we will also explore the idea of using LDO holders as a resolution mechanism for prediction markets and oracles. To protect operators from being unjustly accused, we will design a mechanism that allows such operators to raise a flag and notify the DAO of the resolution mechanism’s wrongdoing.

This part will take 8 weeks.

TASK 4 Heuristics against Sybils and white-labels

We will analyze the possibility of using heuristic mechanisms to detect Sybils and white labels by analyzing their behavior and setups. We will analyze the available literature on the topic and determine operators and the parameters that should be observed. Finally, we will draft a mechanism that, in conjunction with the arbiter protocol, could be used to detect Sybilling or white-labeling operator.This part will take 4 weeks.

TASK 5 Do you trust your white-label?

We will investigate a mechanism that will require from parties using white-label operators to trust them with some funds. More precisely, in the mechanism the party joining Lido will need to put some collateral that can be transferred using validator’s key. Hence, the collateral could be efficiently stolen by the white-labeling party that keeps the key.

This part will take 2 weeks.

On implementation

This phase does not contain implementation. This is since at this stage of research it is impossible to tell what should be implemented, how, and how long would it take. We will propose a proof-of-concept implementation for one of the solutions designed in TASK 4 or 5. We will submit a separate proposal for the implementation effort as soon as possible.

This phase will be completed within 22 weeks from the date of the agreement.

This phase does not contain any implementation.

Organization, Funding, and Budget

The project will be funded by Lido DAO. The DAO will pay Nethermind 450 000 DAI, of which 200 000 DAI will be paid upfront and the remaining 250 000 DAI on delivery.

At the end of the project, the LEGO council will decide whether the provided systematization of knowledge meets the agreed requirements and, if that is the case, proceed with the payment. In the case of disagreement between the LEGO assessment on the quality of the deliverables and Nethermind, Lido operators will be used as a resolution mechanism.

The payment will be made to address eth:0x237DeE529A47750bEcdFa8A59a1D766e3e7B5F91