The purpose of this thread is to collect discussion and community alignment with regards to min-bid usage by Node Operators participating in in the Lido Protocol.
As a start, I propose we begin the discussion based on Irina’s post from the relay voting proposal thread.
In general I think that ~28-40% of blocks produced locally sounds about high but isn’t a prohibitive starting point, although a maximum APR decrease of 15% sounds high, given that it’s currently not easily discernable what effect this level of local block production would have on ameliorating overall service degradation in the network. That said, due to how min-bid works, it’s to be expected that APR effects will be worse during lull periods (vs busy periods), so if based on feedback the NO community feels that overall more validators would opt in than the estimated 60%, the configured min-bid can be lowered.
I propose that the DAO can make min-bid > 0 an opt-in measure for NOs who wish to use it, with a value up to (but not exceeding) the initial suggestion of 0.07, which can then be tweaked down if either large negative effect on APR and/or higher usage of min-bid than expected is noted, and then after ~1-2 month of usage and hopefully with some initial results from RFP: Ethereum censorability monitor to fine-tune the suggested min-bid value based on:
how many NOs are actually using min bid > 0
approximate effect on amelioration of (possible) service degradation
Generally, we appreciate the effort and we would like Lido to be censorship resistant.
In general I think that ~28-40% of blocks produced locally sounds about high but isn’t a prohibitive starting point, although a maximum APR decrease of 15% sounds high
On the other hand, we feel that a maximum of 15% decrease in APR is not to be underestimated.
We discussed this internally and if the APR decrease would be in the 5-10% range we would be much more confident to say yes.
We also did not want to say we opt-in now, but not do it in the end, as this would skew calculations and projections for other NOs.
I propose that the DAO can make min-bid > 0 an opt-in measure for NOs who wish to use it, with a value up to (but not exceeding) the initial suggestion of 0.07 , which can then be tweaked down if either large negative effect on APR and/or higher usage of min-bid than expected is noted
Min-bid should be a must, not an opt-in. The decentralization and censorship resistance of the network is non negotiable.
However the value to be used needs to be discussed, targeting 1/3 of blocks locally or a 5% APR decrease for example.
I think it would be good to set some lower bound however. i.e lowest <= min_bin <= max.
In general operation, I’d like to think that we’d prioritize local block production over block builders especially if the monetary gain to us using a block builder is very small. I don’t have a number for lowest, but perhaps something that would reduce the overall APR <5%.
If an NO can use anything in between 0 and the max suggested I’m not seeing a strong reason for an enforced lower bound. IMO there are two overriding concerns here:
NOs cannot be forced to use min-bid (for the same reason all NOs cannot be forced to use any specific set of relays or specific categories of relays – overriding legal/risk/operational assessment concerns);
Local block production in general moves away from the “validators should be dumb pipes” principle and introduces concerns about MEV hiding, off-channel payments, etc. which all have to somehow be answered or monitored, and the operational work and complexity to do that is very high. The concession made here is that in order to address concerns about service degradation on the network there is a that proposal which may prove effective from a practical standpoint in the near-term until more robust solutions are implemented, and it makes sense to try it out.
There are some additional minor benefits to setting a min-bid of zero (or having a sub-set of NOs which do) e.g. you’re not “late to the party” in terms of figuring out if there’s something wrong with relays.
I would also add to this that setting a min-bid helps to reduce the requirement of always using an external builder/relay for every block produced, sometimes for little revenue benefit. Building more vanilla blocks decreases the risk of missed/orphaned blocks due to things like latency/configs or other external problems which may arise. And of course, less censorship potential. We’ve already seen a few orphaned blocks which could have been prevented by just publishing a vanilla local execution block - with very little difference in revenue.
Though, I also agree that this should be a setting based on a node operator’s evaluation and if we can come up with a maximum threshold for min-bid, that should be the only enforceable parameter.