IMO: this proposal is for something of great value to Lido protocol. Incorporating zk oracle checks will make a risk of oracle misbehavior or an oracle software bug smaller. The challenges on Lido protocol side here are:
- there’s quite a few different things lido oracle do, and it’s not practically possible to replace them with zk oracles all at once
- zk tech is pretty green, I think that the safer way to incoporate it is not to
- additional computation and gas costs here is pretty bulky; having a reasonable upper limit on time and gas costs of delivering a value are important
- the changes in oracle code onchain should be aligned with the cadence of upgrades for the protocol itself, which is usually 6-12 months between upgrades.
This proposal is mostly aligned with this, with an exception to the timelines (there’s no time pressure to implement things fast, actually - they won’t be incorporated fast, there’s time to spare for polish), and thus maybe we can afford a code that would use a more precise way to understand what validators are a part of Lido set than checking by withdrawal credentials.
On the ask side:
- $90k for a zk proof oracle implementation for a three of the simpler outputs is a reasonable ask, IMO
- the hack used to compute the balance (relying on withdrawal credentials) is not fully reliable; e.g. it would fail to deliver correct value on the testnet now, because making a deposit with Lido withdrawal credentials is permissionless
- I think it’s reasonable that audits of smart contract code used by Lido are fully or partially compensated by Lido DAO but I don’t think it’s a good idea to precommit to them before the actually usable system is in place, or there’s an understanding of who can actually audit zk code; I suggest leaving this question for the future, when there’s understanding that:
- the code in question goes into upgrade proposal
- who could be the best firms to audit this code, and what’s their ask.