Here is the post I was talking about:
7 Likes
On the first glance this looks like a really good idea. Need to think a bit more about it but to me it looks like it’s a really a good fix here that is 10x easier to deliver than crlists
3 Likes
@dapplion @michaelsproul @Adrian
What are your thoughts on this?
In terms of short-term implementation, I think this works decently well because it’s immediately implementable and still works within the spirit of the policy: node operators that want to opt into this can, and those that can’t won’t, and the overall effect on staker profitability is kept at an acceptable level. Two questions here are around coordination and monitoring: how do we determine what the right min_bid is, how is that value propagated to NOs, and how do we ensure that the min_bids are set at an acceptable level, but I think these are easily solvable (and e.g. the reference block calculations can take the latter question into account).
The only downside here is that you lose a little bit of reflexivity in terms of being able to identify issues with relays right away (e.g. if min_bid > 0 one may only realize that there’s issues with a relay later than someone who is using min_bid == 0, but hopefully via 3rd party monitoring/alerting services we may be able to still propagate this happening to NOs quickly).
3 Likes
I think it’s a good idea. However one of the purposes of Lido DAO is high APR. Can the above solution be a hindrance to high APR?
Both ignoring some relays from the must-include list and setting a min bid below which relays blocks are ignored lowers the APR for Lido stakers marginally. However, the benefit would be to increase Ethereum’s censorship resistance, which is also in Lido’s interest. I don’t think it should become the norm for all NOs to use a mev-boost configuration that doesn’t maximize APR but if only some do it, the APR sacrifice for Lido should be very small.
6 Likes
I’m in favour of the min bid approach!
I think setting it so that say ~35% of blocks are constructed locally on average would be good?
I guess this would supersede the other changes to the relay policy, except maybe the must-include → should-include change?
(edited 40% → 35% as the flashbots post has nice numbers for 35%)
3 Likes
I think 1/3 on average with >1/3 over lulls and <1/3 over high economic activity period sounds reasonably good, and changes to that should be metric-driven (e.g. if we find out it doesn’t help well enough, then it should be moved).
Looks like the limit should be dynamically calculated using moving average of or something like this.
2 Likes
Shouldn’t be a big problem IMO. Low-activity blocks don’t bring that much MEV on the table anyway, it’s power law.
2 Likes
Following the the discussions from the community call (recording is up!) and the proposal from flashbots to use min-bid for immediate increases to censorship-resistance, I think it makes sense to delay Snapshot votes on the Relay Voting and V2.0 of the Block Proposer Rewards Policy (and thus v1 of the policy would stay in effect). We can target something like early December.
In the meantime, Lido contributors and NOs can work on incorporating min-bid auctions opt-in into the proposed changes for 2.0 of the policy, and time can be given to possibly increase the selection of relays (e.g. asking relayooor to apply in the Call for Relays thread).
6 Likes
Also in favour of this approach with min bid. I would like to see us periodically review this min-bid amount to ensure we can be reactive to targeting a percentage of blocks to be constructed locally since it is very dynamic. ~35% seems to be a good number based on the data from Flashbots article.
2 Likes
Hey everyone. Gnosis just announced a new relay: it is a clean fork of the flashbot relay and it does not apply any block filtering.
- publicly available,
yes, check out: https://agnostic-relay.net/ - publicly listed & maintained,
public announcement: https://twitter.com/GnosisDAO/status/1597940022660894721 - open source,
yes: github. com/gnosis/mev-boost-relay - transparent about what (if any) transaction or address filtering they enforce.
no filtering
Please let us know how to proceed to get included on the allow list.
8 Likes
Hey Martin, this is great news!
Would be great if you cross-post this info to the call for relays threadhttps://research.lido.fi/t/lido-on-ethereum-call-for-relay-providers/2844 , in the meantime do you have a goerli relay set up so that the node operators can begin testing it?
3 Likes
Hey everyone,
Taking into consideration three parameters which guide an optimal min-bid choice: amount of blocks produced locally, change in Lido’s protocol APR and percent of validators who do not opt-in to use min-bid functionality, we developed a model. The key driver in the model to determine an appropriate min-bid is the expected usage of min-bid across Lido validators.
Based on an approximation that ~60% (i.e. 40% do not) of all Lido validators opt-in to using min-bid, the model yields a recommended min-bid value of 0.07 at which an estimated minimum 28% of all blocks produced by Lido validators will be produced locally, with a maximum protocol APR decrease of 15%.
Indicatively, the model yields that if 80% or greater of Lido validators opt in to using min-bid, the min-bid value could also be set to 0.05 with similar results with regards to % of blocks produced locally and a maximum APR decrease.
Model
17 Likes
Two cents regarding ops around the list maintenance.
I’d say, that if Lido wants to have the process nimble, and the list as open as possible, having it straight behind the DAO (Aragon Agent contract) & requiring the full Governance Process for any change is quite too heavyweight.
The relay list contract has a dedicated slot for the “manager” — the address able to administer the list and nothing more. In ideal case there should be EasyTrack motion type making those changes 1) visible; 2) objectable by the community. That’s something we’d need to work in the future, but — alas! — not available from the get-go. I’d say that building an open process around relay list management could leverage some multisig committee as an intermediate solution, basically allowing to expand the list fast enough and keep the “proposed options” wide & visible for all the Lido NOs.
6 Likes
Thanks for the input here. In that case I can roughly see the below as something that works for the interim (but with a commitment that we move to Easy Track this ASAP) given that there will probably be a need to add or move relays somewhat nimbly in the next few months.
- Set up something like a 4/7 or 5/7 multisig with a varied amount of parties:
- 1-2 lido contributors (e.g. someone from NOM team and/or tooling team, since they have intimate familiarity with relay operators and performance)
- 2-3 node operators
- 2-3 independent parties
Multisig can be authorized by the DAO (via snapshot vote) to make changes to the relay lists and proposes changes to the lists publicly (on the forums) before effecting them, allowing for DAO/community discussion to happen.
This will allow the protocol to be a bit more nimble in the short term with regards to adding and moving relays between the list which is probably a good thing given that a lot more relays are coming out (which is great).
I guess next step would be to come up with list of possible participants. Are there any NOs / community members interested?
10 Likes
I’d be interested. Already doing mSig for other protocols.
And yes I think being more nimble is good.
5 Likes
raising my hand here too—happy to help the DAO move nimbly to respond to a fast changing landscape.
on relevance; at Rated we’re among the first to build transparency tools for the emerging relay landscape (e.g. Rated Network Explorer) and continue to put resources to work in that direction.
5 Likes
We agree with this solution in the interim at ChainSafe and would like to signal participation to help with this.
4 Likes