On behalf of Nethermind Research, in fulfillment of Phase II of Research for Lido DAO.

Overview

The following deliverable represents the culmination of Phase II of a multi-phase research project for Lido DAO, with the goal of designing a mechanism for decentralized maintenance of Lido’s operator set. The project is one of the steps toward enabling Lido to onboard new operators in a permissionless manner. (Phase I involved a systematization of knowledge of decentralized identity and verifiable credentials and was delivered in late 2022. Phase II was approved in March 2023 and the corresponding research proposal can be found here.)

In Phase II of this research, we have explored the research and design considerations behind a decentralized dispute resolution mechanism for the Lido protocol, created to punish misbehaving operators. Although this mechanism could be employed against various types of operator offenses, the scope of this phase focuses on those that use *white-label services—*in other words, operators who delegate the operation of nodes to a third party without the protocol's knowledge. Our motivation to fight white-labeling stems from the fact that an entity offering these services could control multiple operators behind the scenes—leading to disproportionate control over the stake and the Lido 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. Therefore, it is in the interest of the Lido protocol that its node operators run their own infrastructure—a goal that this mechanism aims to support and uphold.

To design a dispute resolution mechanism, we first identified a wide variety of protocols that could be used to rule over a white-labeling dispute. Among these, we went over decentralized oracles, prediction markets, and decentralized justice—which we will henceforth refer to under the umbrella term of arbiter protocols. We proceeded to perform a systematization of knowledge of these arbiter protocols, analyzing 35 related papers and implementations and providing a comparative review of the preeminent approaches.

With the clarity achieved from this task, we provide our recommendation on selecting an appropriate arbiter protocol for the problem at hand and the parties that should be involved in providing a resolution. Next, we scoped out the architecture and design required to use an arbiter protocol to punish white-label operators. Notably, our mechanism should introduce the correct financial incentives, so that the following conditions are satisfied:

• Operators using white-labeling services should be punished such that the expected financial return of using these services is negative.
• Honest operators should have a positive expected return from their services, even in light of potential misaccusations.
• External parties should be able to make a profit from acting as accusers against white labels—that is, gathering appropriate evidence against these malicious operators and presenting a case in the dispute resolution mechanism.

We have also aimed to provide clarity on the evidence types that accusers could gather against cases of white labeling. An example involves using heuristic approaches to detect Sybils and white labels by analyzing their behavior and setups. Here, we reviewed the available literature and ecosystem insights on the topic, and have provided the currently known guidelines of which validator features to observe to achieve such a task. Since this tool is likely to lead to an adversarial game between white labels and the heuristic models, our approach here cannot be prescriptive, lest it become obsolete. Instead, we have ensured the dispute resolution mechanism has the correct financial incentives to encourage external model builders to “hunt” these white labels and get compensated.

Terminology

Throughout our research, we employ the following definitions:

• Operator: A party that runs—or participates in running—one or many Ethereum validators. Operators, solely or jointly, have access to the signing keys of one or more validators but do not necessarily have control of the corresponding withdrawal credentials. Operators can control multiple nodes.
• Node: A virtual sub-party (a piece of hardware and software) controlled by an operator that performs the operator’s jobs w.r.t. a concrete validator. When an operator is a party that may control multiple validators, a node is a representation of a concrete validator.
• White-label operators: If a party, who was onboarded as an operator, delegates the operation of a node to another party, we call the latter a white-label operator.
• Sybil operator: We call a party Sybil if it controls two or more operators behind the scenes. A Sybil-protection mechanism is a set of countermeasures that makes it difficult for a party to have two (or more) operators onboarded such that the protocol is unaware they are colluding.
• Arbiter protocol: We call a protocol “arbiter protocol” if it is either a decentralized oracle, prediction market, or decentralized justice protocol.

Results

Here, we deliver the results of our Phase II research, in accordance with the scope and tasks established in the proposal.