> Well, in the simple (and common) case somebody holds the private key and updates it.
I will grant you "simple", and maybe even "common"... but only because most people don't really understand decentralization and many of the ones who do don't care about it.
The "actual" way this happens, for the protocols and contracts that "actually matter" (certainly almost everything you would have heard of, as opposed to the long tail of tiny pet projects) is that, in the case that a bug is found, all of the users have to vote with their feet to move to and accept a new one.
Essentially, this is equivalent to saying "decentralized contracts simply aren't upgradable", but of course everything is upgradable if you accept the idea of people giving up on old software and using new software ;P.
(If this sounds familiar, it should be: this is in a very real sense similar to how Wireguard intends to deal with cryptographic breaks in its chosen cipher suite, as they aren't some centralized power able to upgrade everyone's computers remotely.)
(FWIW, there is something else you can do, but as it would be implemented by still more contracts that themselves might have bugs I don't consider it the answer here as it begs the question: you make a contract--hopefully a simpler one that is less likely to have a bug--that lets people vote on which contract is the current accepted one, assuming they can all have compatible APIs.)
> I will grant you "simple", and maybe even "common"... but only because most people don't really understand decentralization and many of the ones who do don't care about it.
So assuming that this is mainly an issue of people not understanding versus understanding and not caring (though you said there’s some of that) how is the Ethereum community going to get the word out so that this becomes a mainstream success versus mainly for speculation as it is now?
A common issue and one that I personally feel crypto in general suffers from is that neat tech isnt a a criteria on which most people flock to use something so what are the reasons end users need to know to be like ah yup I will drop my regular finance interactions for this or heavily augment them with this?
It helps to consider the context of finance as glue that helps make the real economy move by reducing fraud. Deciding to use a crypto solution is like deciding to use double-entry accounting: it creates a quick and reliable record of transactions in a certain context, this context being one of consent. Putting consent mechanisms on-chain gives many of the benefits of a trusted third party without designation of an actual fallable, corruptable person or institution. That allows the surrounding regulatory framework to be streamlined and take on more and smaller cases with a lower footprint. But there is a chicken and egg scenario there since the norms have to shift towards these solutions before they gain all the desired efficiencies.
That said, I was paid in crypto the other day through a DAO. I was told how to submit a proposal to be paid, and then the funds were released through a vote within hours. It was transparent and the only hiccup was in needing a 70 cent bond fee to submit the proposal - it wasn't "controlled" in the usual sense of assigning a person to handle funds. So I already see some benefit in organizational structure.
Hmm yeah that is certainly interesting in the sense that it was easier to receive payment than it otherwise may have been in current financial systems. Easier to trace and such too I imagine if it was needed.
To your point about transparency and trust for general transactions, I can see how that will be useful but don't you lose the ability that most trusted entities have now which is to roll back the transaction or correct a situation if fraud has occurred, given what I understand to be the finality of a contract? That said, I'm personally not really worried about making a transaction over say VISA's network but I am concerned about the end party I'm interacting with and I feel like crypto in general doesn't do well to address that, which I almost feel like is the real issue. I don't think I understand why people feel like it's an issue if they have to transact over a bigger central authority, perhaps I'm just too far removed from the group of people not served by classical finance.
I question your premise. If you analyze "by weight instead of by volume" then I maintain that all of the important projects you hear about--think of the decentralized exchanges or lending platforms, such as Uniswap--do not have back doors in their contracts for centralized code updates: when Uniswap wants to build a new version, they release a totally new system that happens to share a name.
That there are a large number of silly projects most people haven't heard of, or random tutorials on the web for getting started in crypto, that involve building contracts with backdoors is no different from any technology... most stuff isn't scalable or even slightly secure, even if the products from the biggest companies and used by the most people tend to be: like think how many websites have ubiquitous SQL or HTML injection attacks... only "by volume" (looking at the total number of such websites, irrespective of how much use they get) as "by weight" (looking at the websites you use during the course of a day by how much you use them) I bet almost none of them do.
> to deal with cryptographic breaks in its chosen cipher suite
Interestingly, this is actually almost doable in the context of a decentralized contract/computing system (with bug bounties to incentivise reporting[1]). You can include in the contract a interface where someone provides a proof[0] that a given cryptographic primitive is broken (eg a pair of colliding messages for a hash function), and the contract self-modifies to no longer trust that hash function.
The other half of the process - adding new primitives - is harder, since you want to prevent the addition of deliberately broken primitives. Obvious ideas include requiring a machine-checkable proof of hardness from some reasonable axioms (eg ZFC + P!=NP + whatever else), although most primitives don't have such proofs, and that doesn't look likely to change. Or requiring a quorum of reliable-seeming cryptographers to vouch for it (refutation: NIST endorsed Dual_EC_DRBG). A escrow period, where a new primitive is accompanied by a deposit that's paid out to anyone who breaks it, might help, but you'd need a seperate mechanism to prevent NOBUS backdoors (again, see Dual_EC_DRBG).
0: Ideally, you want a semi-zero-knowledge proof such that someone who has the option of putting in a tractable but significant amount of work to prove it (eg hash collision in 2^64 operations) will expect to be able to recoup their losses without getting sniped by front-runners, but once such a proof has been used, it's only a matter of time before front runners recover it and warn every contract.
For hash collisions, probably the easiest design is a two-phase model, where the reporter provides a zero-knowledge proof to commit to a particular hash collision, but then has to provide the actual collision to get the bounty. This can also work for preimages of a Schelling point like all-bits-zero. I'm not sure what a good Schelling point for typical public-key cryptography like curve25519 would be though; zero is almost always algebraicly special.
1: Cryptographic primitives are generally broken incrementally, so this incentivises even malicious parties to report a not-yet-exploitable break immediately (and thereby neuter it), rather than spend time trying to develop a working exploit (and risk both the large and small rewards disappearing out from under them because someone else was either honest or just less patient).
Axie as a product isn't even remotely decentralized, as far as I can understand (though I haven't tried to really pull it apart or anything, though I did spend way too long researching it a couple months ago): the majority of its product is a centralized gaming server that uses classic cheat-protection and rate limiting strategies, along with a game client that they require you to be using--they even ban bots! think: how can a decentralized game ban bots?!--which is important as it is effectively centrally minting its SLP token (by way of how that token comes from points you earn in the game from game play; this "should"--if it were actually decentralized--result in everyone using bots to play each other constantly for maximum SLP earning, instead of hiring people in the Philippines to play your characters for you). One would do better to ask "in what ways is Axie Infinity even a blockchain project?", as I feel like the answers are mostly going to suck.
I will grant you "simple", and maybe even "common"... but only because most people don't really understand decentralization and many of the ones who do don't care about it.
The "actual" way this happens, for the protocols and contracts that "actually matter" (certainly almost everything you would have heard of, as opposed to the long tail of tiny pet projects) is that, in the case that a bug is found, all of the users have to vote with their feet to move to and accept a new one.
Essentially, this is equivalent to saying "decentralized contracts simply aren't upgradable", but of course everything is upgradable if you accept the idea of people giving up on old software and using new software ;P.
(If this sounds familiar, it should be: this is in a very real sense similar to how Wireguard intends to deal with cryptographic breaks in its chosen cipher suite, as they aren't some centralized power able to upgrade everyone's computers remotely.)
(FWIW, there is something else you can do, but as it would be implemented by still more contracts that themselves might have bugs I don't consider it the answer here as it begs the question: you make a contract--hopefully a simpler one that is less likely to have a bug--that lets people vote on which contract is the current accepted one, assuming they can all have compatible APIs.)