Expansion of Lido's Ethereum Oracle set

Proposals
1

Context

At the heart of the Lido Liquid Staking protocol is its rebasing mechanism, which currently happens daily — rebasing acts to distribute staking rewards to stakers, along with fees to Node Operators & the protocol itself.

Since it is currently not possible to permissionlessly and trustlessly check the balances of Beacon Chain validators from the Execution Layer (where the Lido protocol smart contracts are) — at least until something like EIP 4788 is implemented — the protocol relies on a set of Oracles to be able to check and transmit the balances of Lido validators from the Consensus Layer to the Execution Layer. The Oracle mechanism consists of a set of offchain daemons operated by independent parties responsible for observing & reporting the total balances of all Lido’s validators & the smart contract implementing quorum mechanics for those reports.

That way, the Lido protocol doesn’t depend on single entity properly calculating the balances & reporting those. The current Oracle set consists of 5 participants (all of whom are currently Lido Node Operators).

Requirements for Oracle Operators

  1. Running offchain software—that should be up every day for 1-2h around 12PM UTC (rebase time)

  2. Providing gas funding for sending daily Oracle report transactions

  3. Whitelist the address through the Governance process

The Oracle Operator Manual contains details on setting up and monitoring an Oracle.

The Proposal

Securing Oracle operations is important to ensure the robustness of one of the core mechanisms that underlie the Lido DAO. Increasing the Oracle set & welcoming trusted third parties should be a win for DAO.

The DAO is considering increasing that number to 9 (5/9 consensus) or 11 (7/11 consensus) total entities, with a preference for participants who are not currently Node Operators. Additionally, it can be argued that it would be beneficial for the protocol’s safety & resilience, so that’s something the Lido team would 100% be looking forward.

:speaking_head: This is an open call for parties who may be interested to join Lido on Ethereum’s Oracle set. Based on interest received, the DAO should decide by how much the Oracle set should be increased and which new participants should be added.

Open questions for discussion

  1. Should the DAO increase the size of the oracle operator set?
  2. Should oracle operators be remunerated for their services–especially if these are third parties that do not have a revenue stream that is tied to Lido (as NOs do for example)? If so, how and by what margin?

About the author

I am the co-founder of Rated, and a member of the Lido DAO since the first Treasury Diversification Proposal. You can find more about me here.

Note: Rated would be looking to participate in Lido Oracle set as a third party, subject to terms.

16 Likes
2

Addendum: In the spirit of getting everybody the right information to make an informed decision, I’ve prepared an analysis of the on-chain costs oracle operators have borne over the past 19mos of operating (accessible here).

Note the estimates do not include off-chain server-side costs and other operational overhead that the operators incur.

4 Likes
3

Wow! Really excited about this proposal. I do think that extending the Lido Oracle set & welcoming third parties makes massive sense, looking forward to it!

1 Like
4

I’d say it may be well worth it to compensate for gas costs for existing and future oracle operators. We’ll prepare the analytics required on the numbers there, but I’d argue it makes sense to operationalise those expenses in the same-ish vein as deposit bot (starting point: Proposal to fund the depositor bot in Ethereum)

2 Likes
5

I would argue that this is a given – the DAO should absolutely refund gas costs to all oracle operators (and for expenses already incurred this should happen ASAP) and it should put in place a process so that these costs are either covered up-front based on a best-effort guess (+buffer), or repaid on a timely schedule (e.g. maximum once per month). Both could be accomplished in a clear and simple manner via something like Easy track.

Oracle operations should be fully transparent and included in the calculations of determining protocol profitability etc, so the closer this is tied to on-chain ops/governance the better.

On the larger initiative proposed by @eliasimos I fully agree and think it would be great to increase the oracle set, although based on Elias’ calculations it seems that the overall cost increases quite considerably as we add more members. Would something like rotating the oracles work? E.g. if we grow to a set of 11 but for each week there is an “active” set of 8 (7 for consensus and 1 backup) oracles that are “on duty” for that week?

3 Likes
6

There’s no increase in costs for online oracles (only “quorum” number would be paying for gas), so don’t think that’ll make much sense — I’d rather had full-ish set online at all times for resiliency.

1 Like
7

Ah ok so “late” or “after quorum” oracle check-ins gas is returned?

8

I think offchain daemon code doesn’t send those, tbh

9

WRT 3rd party oracles, I whole heartedly agree that we need them and should cover gas.

WRT current oracles, I am less eager to refund for prior months. I have not heard any complaints to date and I believe they were aware of the requirements going in, right? Going forward though, it makes sense to cover all these gas costs to the extent it encourages a more robust, trustless, decentralized protocol.

The margins on Lido are razor thin as it is.

Admittedly, I am a bit shocked at the all in gas costs here. This proposal ought to be immediately followed by a grant to understand how all operators can efficiently operate. These gas costs will be material and saving 100k - 300k a year is worth an exploration.

1 Like
10

Any views on Obol Network? It seems there may be an opportunity to decentralize operators who in turn could decentralize the oracle set? Though, I may be in over my head here, technically speaking.

1 Like
11

The protocol needs oracles so that it runs properly (it doesn’t have to do with the node operators themselves). Currently the oracles are operated by some of the initial node operators, and they were nice enough to do it but by no means should it be a “hidden cost” for them (recall that this is just gas we’re talking about, and not the time/devops that they’ve put in gratis). No one has complained because they’re all nice people but the protocol should not rely on volunteerism to be functional. I think it would be pretty crappy of the DAO to not reimburse these costs back to them.

7 Likes
12

I do see your point. I’m not sure I see it as quite so altruistic, as they are indirectly benefiting from their oracle services with Lido.

Out of curiosity, do you have any idea if it would be possible to use Chainlink or another oracle service for this? And what the costs might be?

I think we are in agreement that we ought to pay for this, so I am curious how we optimize it.

3 Likes
13

I would be very against leaning fully on third party provider for vital protocol functionality. Don’t get me wrong: chainlink is the crucial partner for Lido allowing AAVE & other money market integrations to function properly, but that’s the thing outside of the staking protocol in the heart & core of Lido

2 Likes
14

Note that it’s not every NO from initial set, so discriminating there doesn’t make much sense for me, tbh

2 Likes
15

Obol is to solve for more specific case and won’t help us as-is with Consensus layer Oracle; though later (maybe quite some time later) other venues, i.e. permissionless Oracles could become possible. Until then having more diverse & resilient Oracle set seems like a vital thing for Lido to care for

16

We [Kukis Global] are interested in joining the Oracle set.

We have been onboarded as a node operator to LIDO ETH during the latest round.
We are also running one of the Chainlink oracles since 2019.

4 Likes
17

Chainlayer is interested in being an operator for the Lido Oracle set.

3 Likes
18

Thanks for jump starting these conversations Elias! It’s about time Lido also expand the oracle set to additional operators. I don’t think there are that many arguments against increasing the number of oracle operators.

Similar to how we onboard new validators, we could have the same process copied over for selecting the oracle operators, and perhaps use Chainlink (I think most validators are Chainlink operators as well) performance to assess the candidates.

2 Likes
19

Makes perfect sense to increase the number of oracle set as Lido has grown significantly and requires more decentralisation and security enhancement. And I’m totally supporting the compensation of the gas cost.

In the spirit of enhancing Lido’s security, I’m wondering what is the optimal composition of oracle participants. Having full set of third-party independent providers may prevent any collusion to attack the Oracle and also the chances of massive downtime is low, but they may also not be fully aligned on Lido’s interest. Is there any major concerns about existing Lido node operators to be an oracle?

Nevertheless, RockX (existing Lido node operator) is happy to run the Lido Oracle if Lido needs.

1 Like
20

CryptoManufaktur, existing Lido node operator, is interested in running a Lido Oracle.

Gas cost compensation sounds right. This is a lightweight service that can run on existing infrastructure.

3 Likes