It is the responsibility of developers, engineers, and architects to ensure that the software is maintained, that systemic failures don’t occur, and that when they do (as will happen, because of the sorry state of the software development indus…
The problem that I have with this is you are not stating your assumptions clearly. Yes I agree this is what the developers should try and do. Unfortunately this is not what developers have done in the past and it is likely not what they will do in the future.
There is a very fundamental aspect of blockchains that you are overlooking here because you simply haven’t carefully considered our past.
The fundamental problems of every consensus system ever designed up to this point is in its security model as it pertains to really large escrows (contracts holding a large amount of funds). No blockchain protocol has ever, or likely will ever, enforce a hard cap on the size of funds which can be placed into a contract (escrow). There has never been a protocol (that I am aware of) which forbids the creation of an escrow (contract) where the value of said contract exceeds the security model of the protocol on to which the escrow is built.
In reality it contained nearly 20 to 30% of all ETH which was actively in circulation at that time. I say this as a friend, “How does this much ETH in one contract not break ETH’s security model?”
Few questions for you to consider:
- What is the likelihood that the reason for Ethereum classic’s existence is because the protocol developers for Ethereum neglected to enforce a hard cap upon the value which contracts and escrows were permitted to hold?
- What would have happened if the architects for Ethereum had created a hard cap on the value that contracts and escrows were permitted to hold?
- What if you and Vitalik had specifically acknowledged that there was a value which a contract could hold which exceeded Ethereum’s security model? What if you acknowledged that for any one contract to hold beyond a certain value of funds there would be significant risk of experiencing a contentious fork if ownership of fund became disputed? What if you had acknowledged that some high value contracts could potentially expose the Ethereum protocol and the entire ecosystem to the risk of a contentious fork?
- Do you really think that merely advising dapp developers as to this risk would have made any actual difference?
If you answered,”yes” to question #4 I hope you realize that your definition the word responsibility as used in your statement, “It is the responsibility of developers, engineers and architects to ensure … systemic failures don’t occur” does not match my definition of the word responsibility. My definition is that you enforce via the protocol that systemic failures do not occur. Did you do this? Have you done this with regard to the value that any one contract is permitted to hold? Would you advocate for this when upgrading Ethereum in the future?
If not why not? If so why so? Would love to hear your thoughts.