3 ms·
It's fairly common to deploy a proxy contract, which allows for a sort of updating. Basically you deploy a new contract and have the proxy point to that new con
by ekir 5y ago
It's fairly common to deploy a proxy contract, which allows for a sort of updating. Basically you deploy a new contract and have the proxy point to that new contract instead of the old one. There are definitely some limitations and it's not fully standardized yet. There's a tentative standard here https://github.com/ethereum/EIPs/issues/1538 https://github.com/ethereum/EIPs/issues/1538 and OpenZeppelin also has their own implementation.
Although neither of these things will actually help if your contract gets exploited before you can push a fix.
- acjohnson55 5y agoThe problem there is that it allows people with deploy privileges to unilaterally change the rules. So you lose "code is law". Hypothetically, you want to custody of assets in an immutable contract with the minimal amount of privileges, and use proxy contracts for higher level on-chain functionality. But it's not so clear to me that it's possible to achieve a perfect factoring, in general.
- xur17 5y agoTypically folks require a governance vote (so multiple parties) + a timelocked contract, and then after some system age / volume they burn the option.
- gumby 5y agoDoesn't a proxy contract defeat the whole purpose of algorithmically enforced contracts?
- cmelbye 5y agoI don't think it's realistic to think that human judgment can leave the picture after the first deploy. New systems are fragile, requirements change, and mistakes happen. A certain level of trust is required in the founders of a project. And generally, they have long-term incentives that are aligned with your own.
- elefanten 5y agoSo it implies the crypto maximalist takes on true trustlessness are not proving workable. At least in practice with lots of real users.
- PretzelPirate 5y agoThe systems can be trustless and upgradable. As we get proven/tested/formally verified code that implements governance protocols we can use that code to build system of allowing upgrades while allowing those who disagree to exit the system. For example, one of the ZKRollup chains has a mechanism for upgrading that requires a small number of approvers for the “break glass” scenario. When an upgrade is approved, anyone can exit the network before the upgrade takes affect and move to a system with rules they support. Governance models will evolve as we figure out what works and what doesn’t. Some people may be ok with a super majority being able to revert the state of a contract in response to a bug while others will want immutability at all costs. Blockchain/cryptocurrency is about each participant deciding how much trust they are ok with, and having an open ecosystem where assets can be moved to systems that people want to use.
- cmelbye 5y agoDo you have any examples of these takes? The concept of "true trustlessness" is obviously lacking in nuance and probably impossible. Nothing in the world can exist without some form of trust. However, we can certainly use smart contracts to decentralize trust and limit risk exposure.