| It is a choice at the software later. And who is making that choice? It's the initial people who actually write that software. But what if that system is now affecting many other people, or the entire planet in a significant way? Should they have some voice over that? Under a traditional governance regime the answer is that that is at least possible to change. It may be difficult, but it does not violate the laws of physics and can happen in less time than the heat death of the universe. But we can now write software that makes it functionally impossible for anyone to make that choice, even potentially the original designers. That is an option that we did not have before. It's in some sense the essence of trustlessness. In some cases, this might be the right trade-off. For example, beyond the blockchain, this is also a way to think about encrypted communications. It is a very significant new power that we can now wield. But it must be wielded carefully, and that doesn't seem to be happening. So yes, blockchain applications don't need to be irrevocable. But the ability to make them so is something that could have a very significant implications—potentially negative. As a somewhat tongue in cheek example, but with a little bit too much reality to be comfortable, this irrevocability might allow you to "create" a paperclip maximizer DAO (incentivized at the social layer, with humans doing the work). |
This is an important point you are making. What you must recognize is that they absolutely can have some voice over that.
Just as we can write software (or smart contracts) that allow no one to update and fix such issues. We can write software that allows one person to do it. Or we can lock the ability behind a multisig, requiring a majority of the software's developers to do so. Still not good enough for the use case due to far-reaching trust ramifications? Then we write code that delegates the ability to trigger such an update to the entire userbase of the application.
In the world of contract platforms, you have to keep in mind that contracts and the tools that you can build with them are primitives. They are composable. There is no problem in building a DAO to control the ability to update a contract (or trigger arbitrary functions to remedy critical situations caused by unexpected and undesired state changes). This is already done in practice in various applications--and sometimes with undesirable outcomes! Of course, these are still experimental times and lessons are still being learned.