Thanks Stefan for kickstarting the discussion! One of the great things about decentralized protocols and DAOs is the many different ways you can approach a challenge or set of problems. I think the guiding questions you’ve posed are certainly in the right direction, but perhaps disagree a bit in terms of follow-through.
I would like to try to lay some groundwork in terms of how I think of the protocol:
- The Lido on Ethereum protocol is essentially software / middleware. It doesn’t have agency and can only do things which it is programmed to do, either as a reaction to things that happen to/from it, or through interactions with it by third parties.
- The DAO, to the extent through which it can action things (via votes), should attempt to be a guardian of (a) the protocol (lido on Ethereum), (b) its users, and (c) the underlying network. It’s essentially a utility maximization <> risk minimization exercise.
- Because Ethereum is stronger when it’s robust, this means things like fostering decentralization, diversity, and variety, versus picking just what is “most profitable” and focusing on that.
- As the protocol matures, the things which the DAO can do and its total power of the protocol should minimize, and its role in the routine functioning of the protocol should basically end up somewhere between “none at all” to “in case of emergency, break glass”. There are technical limitations (e.g. lack of withdrawals until recently, ability to consume beacon state in the EL directly, etc.) which substantially affect the potential and practical mechanisms of trying to make the protocol fully autonomous, but DAO involvement it should be minimized at every step of the way based on context, protocol design decisions, and technical environment limitations.
What does this mean for NOs and other entities interacting with the protocol and the DAO? I agree that it makes sense to have a more structured approach for how the NOs interacting with the protocol may deal with emergencies / incidents, however, as far as the DAO is concerned, I think the approach should be more of something like a policy rather than a procedure. Basically: it should outline what the goals are, what the expected results are, and what happens if the expected results are not achieved. Node Operators can then be encouraged to do their own thing, in their own way, within the set of objectives that aim for a robust validator set for the protocol and Ethereum. Ideally, NOs collaborate and coordinate on developing these operational practices and they (and the wider community) hold each other accountable, vs needing the DAO to do it.
- I don’t think the DAO should enforce or be involved in the reviewing/checking of specific practices (eg via workstream contributors). I think the community of NOs can certainly do so, and there can be a culture of sharing of information, tools / processes, and self-reporting relevant information, and the DAO could support this effort (e.g. via grants, open source tooling, collaborations with 3rd parties to offer things like security and process assurance frameworks and audits). But, I don’t think it’s the DAO’s job to be an arbiter or an enforcer of “these are the right procedures” and “do you have the right procedures set up”. There’s a few reasons for this:
- For the protocol to truly be permissionless, NOs should be able to interact with the protocol without requiring this kind of effort by the DAO or DAO contributors
- The protocol’s design should be built to minimize risk via various mechanisms (e.g. selection of professional operators, bonding, scoring, etc). As the protocol matures, and more options are available, the manner in which NOs can interact with the protocol will widen, the number of NOs who interact with it will increase drastically, and it is not practical for the DAO to enforce anything that isn’t results-based.
- Establishing and requiring conformity amongst practices can lead to correlated failure and doesn’t allow for NO “opinionatedness” in certain things where an NO may do things differently for a variety of reasons (and doing differently is fine, provided that it’s done correctly).
- Instead, assessment of these things can be largely results based, kind of like the approaches followed in the proposed Validator Exits Policy and the ratified Block Proposer Reward Policy. The latter does entail a measure of “this is how you should do it” given the large set of technical and security considerations, but the policy itself stipulates that other mechanisms could be utilized by NOs provided they are discussed, assessed, and tested first).
- NOs can and should be encouraged to co-develop these detailed operational and security processes / practices / standards and self-regulate.
- The DAO then only really needs to worry about getting involved in edge cases where, for example, self-regulation has failed, the protocol has been endangered, serious outages / incidents may have caused doubt with regards to the continued performant or sustainable operations of an NO, “real world” (meatspace) events which the protocol cannot address necessitate action, or the trust between participants in the protocol has been damaged.