bloXroute is interested in becoming an operator for the oracle set.
Matrixed.Link, a Chainlink Node Operator active on 7 chains, is interested in becoming an operator for the Lido Oracle set.
Kyber Network is interested in being an operator for the Lido Oracle set.
https://kyber.network/
We are pleased to announce that we are finally ready to provide the community with a shortlist of potential new oracles for onboarding. We are very excited about this process and are committed to decentralization by expanding the set of oracles with third parties.
We onboarded 6 oracles on the testnet. And we are happy to propose the shortlist for further votes to expand the set on the mainnet.
Now we have 5 oracles and 3/5 quorum. The proposal is to add 6 new oracles and set quorum as 6/11.
Shortlist:
We are now ready to take the steps to expand the set on the mainnet. To do this, we plan to launch a snapshot vote in the very near future and then, if the snapshot vote is supported, launch Aragon-vote for onboarding.
If the community has an opinion on this proposal, feel free to share.
How the current oracle 3-of-5 concensus works? All 5 oracles send report tx and the oracle contract only accepts the first 3? or the software uses an offchain picking algorithm to choose 3 of 5?
The shortlist shows non-NO oracles will be onboarded this time. Happy to introduce non-NOs into Lido eco. However, All the 6 candidates are not the direct stakeholders to Lido. How to keep them honest when those 6 are chosen to report beacon stat together.
thanks @satBalwyn; for your first set of questions I think you will find answers through the hyperlinks in the original post.
re: alignment—I can speak for Rated; we’ve been through 2 grants rounds with Lido which we have completed successfully. so far we’ve gotten compensated in LDO (we asked), haven’t sold a single token and holding to a 60% drawdown on avg (see ratedw3b.eth). on balance, marked to market, this means that we have paid to do the work.
to be clear: we approach token based comp as accumulating agency and aligning incentives between ourselves and folks that we work with, with a long term view.
for myself, context again in the original post.
more generally, given that there will be 11 operators whose versions of reality will be medianized, the fact that the role is pro-bono, as well as the fact that the incentives that all net new operators are fairly well aligned with Lido and the NOs that make it up, I would say that the “risk” that you raise is tolerable—at worst, and on balance the proposed set up is a net improvement for the DAO.
Offchain daemons send txs with the reports, on-chain contract receives the first three matching one another to quorum, and that triggers the report finalization along with rebase.
Good q! The teams are pretty ecosystem-aligned as-is, so on the surface of it seems ok to have 6 new members. Other options we can explore are either onboarding, say, 4 new members now & some more later on, or 2) raise the quorum not to 6/11 but to 7-8/11. WDYT?
It’s not even medianized: oracle only finalize if there is enough identical reports.
Could we separate the onboarding into 2 waves this time.
In Wave1, we first onboard 3rd parties to apply the quorom 5/8 (at least 2 old oracles have to report). After certain time (1 mth or 2mth?), introduce the other 3 and use the quorom 6/11 in Wave 2.
BTW, one idea for long-term plan. Since some existing NOs are interested in running oracles, could we consider the regular rotation between the NOs who are running oracles and who want to run. For example, 1 NO oracle is rotated per mth.
Can’t see improvement in safety here. If you’re considering new oracles as potentially malicious (that’s what blockchain people do in general) — getting to higher quorum is a safer option. Two waves is just “we ask you to wait before going rouge” imo. As for the tech tests, all teams are running oracle software on the testnet and are running those fine.
While cool on paper, I’m 100% positive that would either make for a miserable process or would require committee for rotation management (read: another multisig with special access). I’d preferred strong and stable oracle set without major disturbances
Agreed on it!
A quick Q, why we need a multisig committee for rotation mgnt. I thought it could be done by onchain voting (oracle permission update).
However, I do see there will be much async conversation work for coordination before and after the vote, which can’t be replaced with automation in the current system.
The sheer amount of coordination required to push periodic onchain votes on tactical decision / action won’t get us far enough. So: technically possible, really — not much so
@satBalwyn thanks for your opinion and proposal!
We discussed different versions of onboarding within the team, and we also had the idea of onboarding maybe not full set, e.g. 4 oracles first. In this case, those potential oracles that are node operators in other protocols will not get into the set. We will be happy to further cooperate with them as node operators.
As a result, we created a snapshot vote with several options: onboard 4, onboard 6, do not onboard anyone.
I think that in this case, the majority of votes will show us which way we will move further.
Good day all, my name is Jordan and I’d like to provide a brief introduction to Spire:
Spire is a registered company in the US that’s operated by a team of engineers in Texas. Our backgrounds are in midmarket and Fortune 500 Infrastructure & Operations. The company was founded to bring the team’s passion, technical expertise, and core values to Web3.
Spire has supported development with leading blockchain co-founders and projects, operated validators, led fund raises via ISPO, and provided permissioned off-chain services for 2+ years in various ecosystems. A portfolio overview is available on our web site.
The oracle set expansion is a great opportunity to support Lido and its community. While incentives may exist for new oracle operators, our goal is to develop long-term relationships and contribute to responsible growth for the ecosystems in which we participate. We’re committed to adhering to the guidelines set forth by Lido and operating in Lido’s best interest, including maximizing safety and security.
Thanks to Lido and the community for your support!
-Jordan, Principal Operator
For safety reasons, the best approach is to onboard four non-NodeOperators, because, in another case, we would have five old committee members and six new one that is a little bit worse than 5 + 4. I suggest onboarding the remaining candidates in the next round after the withdrawal upgrade (March/April 23).
Hey builders! Anyone want to add his quote to the article? PM me if so.