13 ms·

Upgradeable smart contracts in Ethereum

98 points by zabi_rauf 9y ago

45h34jh53k4j 9y ago
Upgradable infers that the underlying contract address has a new chunk of code. That is not what this is proposing. This is simply making resolving contracts, which is best practise today.
- crispyporkbites 9y ago
  It achieves the same thing though, you call a contract at address A, which is usually proxies to contract at address B. The owner of A can shift the proxy point to address B or any other address. The danger here is that the user calling the contract is not aware of the proxy and the new contract does something unexpected.
  - eudoxus 9y ago
    The way I see it, if you are using a contract and you don't know that there is a sole owner that has the ability to upgrade the underlying contract to something else, which could be nefarious, then that is in the same wheel house as using a contract with a bug in it anyways. It should be standard practice to have some governance model around the upgradeability (IE Multisig, Liquid Democracy, Aragon, etc...). Any contract that doesn't use some governance should be considered insecure and not used for financial transactions on the chain.
akerro 9y ago
I heard that story behind this is that one of close friends of ETH developers lost a few $M in smart-contracts, so they want to be able to update its source code to access the ETH, is that true? How would that work?
- fbonetti 9y ago
  You can't modify smart contract code once it's been deployed, period. Ether that's locked up in bugged out contracts is permanently lost. This post describes a strategy for writing contracts that proxies the actual implementation of the contract to another contract. If the contract needs to be modified, a new contract is deployed and the original contract is set to point to the new contract. Edit: I misread your comment. There has been a discussion over of a possible hard fork in order to recover lost funds, but that's not what the author is referring to in this post.
- ancorevard 9y ago
  Yes, that is true: https://github.com/ethereum/EIPs/pull/999 https://github.com/ethereum/EIPs/pull/999
  - tuesdayrain 9y ago
    It's true, but it's not related to OP's article.
- 45h34jh53k4j 9y ago
  $91 million of Polkadot ICO funds, Gavins ICO. Gavin a cofounder of Ethereum, and the creator of Solidity. So its more like the cofounder of Ethereum lost $91 million dollars in his own wallet, using his own smart contracts, using the language he wrote. I am against the proposal to undo the deleted multisig wallet contract. Everyone makes mistakes, some are worse than others. You can never learn if every mistake can be undone.
- davesque 9y ago
  The article is only partly related to that incident. People have been trying to figure out reasonable mechanisms for doing smart contract updates since before the Parity Multisig matter. What is discussed in the article is being used today and doesn't require implementation of an EIP. The desire to sort out how to do updates is motivated by much more than just that particular incident.
dmart 9y ago
Is immutability of a contract not the entire point? What security does a decentralized smart contract offer if its implementation can be totally swapped out?
- chrisshroba 9y ago
  I think the point isn’t so much immutability for the sake of immutability but rather immutability for the sake of keeping power out of a centralized entity. With the scheme proposed in this article, you could do things like have contract changes only be authorized by, say a 2/3 vote of token holders, or any other complex logic you want to implement in a smart contract. Of course if there is some contract that has a single individual with the power to make arbitrary modifications, it likely won’t be successful, but with decentralized ownership I think it could work.
  - domrdy 9y ago
    Yes, that sounds reasonable. It's kinda worrying that some popular smart contracts implement "Pause" functions, callable only by one address (usually the creator of the contract).
    - crispyporkbites 9y ago
      You, as the user, can see those functions and choose not to use those contracts. With a closed source or black box api you don’t have that power as an individual
      - weego 9y ago
        So in this wonderful future we're building anyone who wants to safely execute a transaction should be a specifically skilled programmer? Sounds more dystopian than other possibilities
        dmihal 9y ago
        Couldn't you say the same thing about the long legal documents that we all sign when signing up for commercial banking products?
revel 9y ago
Injecting a delegate into an otherwise vanilla smart contract doesn't seem like the hard part of creating an upgradeable contract. The hard part is coming up with a consensus model for agreeing to the change. Bilateral agreement doesn't seem strong enough, let alone unilateral agreement.
- JumpCrisscross 9y ago
  > Bilateral agreement doesn't seem strong enough Why not? If you and I agree on something, and then agree to amend it, that's valid.
snissn 9y ago
Very cool! Not applicable to all use cases, but where it is applicable it is a great tool.
Animats 9y ago
Contracts with terms that can be changed retroactively by one party. What could possibly go wrong? The whole point of this smart contract stuff is supposed to eliminate the need for trusting a party. The article has full details on how to create a contract changeable by one party, then hand waving about "writing a contract that uses tokens and voting mechanism to allow the community to decide whether to update or not." No details on how that's supposed to work. Who's "the community", anyway? The parties to the agreement are the ones involved. A mechanism where all parties to a contract could agree to replace it with a new contract would be useful. That's a normal contract activity. You do that whenever you renew a lease. The Etherium promoters want this because they botched the design. Smart contracts as byte coded programs are too error prone. The DAO debacle, and this latest demand for a "state change" because someone botched a big contract, indicate that. Smart contracts should have been in some declarative form like decision logic tables, not Turing-complete programs with race conditions.
- CryptoPunk 9y ago
  >>The article has full details on how to create a contract changeable by one party, then hand waving about "writing a contract that uses tokens and voting mechanism to allow the community to decide whether to update or not." No details on how that's supposed to work. Who's "the community", anyway? The possibilities are endless. You could have pre-chosen adjucators that can upgrade a contract on majority vote. You could use a decentralized prediction market like Augur to trigger a contract upgrade if it deems that certain events occurred, etc. Upgradability is just one component of many that will be needed to create a durable/secure smart contracting system. It's not a silver bullet. >>The Etherium promoters want this because they botched the design. Do you misspell Ethereum deliberately? I only ask because I've seen you comment multiple times about Ethereum with this misspelling, which comes across as very petty. >>The DAO debacle, and this latest demand for a "state change" because someone botched a big contract, indicate that. The latest state change request is overwhelmingly rejected by the community and will not happen. The request is only possible at all because of the temporary state of Ethereum having several hard forks planned that a state change can be snuck into. Once this phase of its life cycle is over, even requests for a state change will not happen. >>Smart contracts should have been in some declarative form like decision logic tables The point of using byte coded programs and a Turing Complete execution environment is to make features like the smart contract programming language totally configurable, rather tied to a single base implementation.
misrab 9y ago
Maybe consensus should only be reached on certain invariants, with the underlying implementation being far more mutable.

98 points by zabi_rauf 9y ago

Upgradable infers that the underlying contract address has a new chunk of code. That is not what this is proposing. This is simply making resolving contracts, which is best practise today.

crispyporkbites 9y ago
It achieves the same thing though, you call a contract at address A, which is usually proxies to contract at address B. The owner of A can shift the proxy point to address B or any other address. The danger here is that the user calling the contract is not aware of the proxy and the new contract does something unexpected.
- eudoxus 9y ago
  The way I see it, if you are using a contract and you don't know that there is a sole owner that has the ability to upgrade the underlying contract to something else, which could be nefarious, then that is in the same wheel house as using a contract with a bug in it anyways. It should be standard practice to have some governance model around the upgradeability (IE Multisig, Liquid Democracy, Aragon, etc...). Any contract that doesn't use some governance should be considered insecure and not used for financial transactions on the chain.

akerro 9y ago

I heard that story behind this is that one of close friends of ETH developers lost a few $M in smart-contracts, so they want to be able to update its source code to access the ETH, is that true? How would that work?

fbonetti 9y ago
You can't modify smart contract code once it's been deployed, period. Ether that's locked up in bugged out contracts is permanently lost. This post describes a strategy for writing contracts that proxies the actual implementation of the contract to another contract. If the contract needs to be modified, a new contract is deployed and the original contract is set to point to the new contract. Edit: I misread your comment. There has been a discussion over of a possible hard fork in order to recover lost funds, but that's not what the author is referring to in this post.
ancorevard 9y ago
Yes, that is true: https://github.com/ethereum/EIPs/pull/999 https://github.com/ethereum/EIPs/pull/999
- tuesdayrain 9y ago
  It's true, but it's not related to OP's article.
45h34jh53k4j 9y ago
$91 million of Polkadot ICO funds, Gavins ICO. Gavin a cofounder of Ethereum, and the creator of Solidity. So its more like the cofounder of Ethereum lost $91 million dollars in his own wallet, using his own smart contracts, using the language he wrote. I am against the proposal to undo the deleted multisig wallet contract. Everyone makes mistakes, some are worse than others. You can never learn if every mistake can be undone.
davesque 9y ago
The article is only partly related to that incident. People have been trying to figure out reasonable mechanisms for doing smart contract updates since before the Parity Multisig matter. What is discussed in the article is being used today and doesn't require implementation of an EIP. The desire to sort out how to do updates is motivated by much more than just that particular incident.

dmart 9y ago

Is immutability of a contract not the entire point? What security does a decentralized smart contract offer if its implementation can be totally swapped out?

chrisshroba 9y ago
I think the point isn’t so much immutability for the sake of immutability but rather immutability for the sake of keeping power out of a centralized entity. With the scheme proposed in this article, you could do things like have contract changes only be authorized by, say a 2/3 vote of token holders, or any other complex logic you want to implement in a smart contract. Of course if there is some contract that has a single individual with the power to make arbitrary modifications, it likely won’t be successful, but with decentralized ownership I think it could work.
- domrdy 9y ago
  Yes, that sounds reasonable. It's kinda worrying that some popular smart contracts implement "Pause" functions, callable only by one address (usually the creator of the contract).
  - crispyporkbites 9y ago
    You, as the user, can see those functions and choose not to use those contracts. With a closed source or black box api you don’t have that power as an individual
    - weego 9y ago
      So in this wonderful future we're building anyone who wants to safely execute a transaction should be a specifically skilled programmer? Sounds more dystopian than other possibilities
      - dmihal 9y ago
        Couldn't you say the same thing about the long legal documents that we all sign when signing up for commercial banking products?

revel 9y ago

Injecting a delegate into an otherwise vanilla smart contract doesn't seem like the hard part of creating an upgradeable contract. The hard part is coming up with a consensus model for agreeing to the change. Bilateral agreement doesn't seem strong enough, let alone unilateral agreement.

JumpCrisscross 9y ago
> Bilateral agreement doesn't seem strong enough Why not? If you and I agree on something, and then agree to amend it, that's valid.

snissn 9y ago

Very cool! Not applicable to all use cases, but where it is applicable it is a great tool.

Animats 9y ago

Contracts with terms that can be changed retroactively by one party. What could possibly go wrong? The whole point of this smart contract stuff is supposed to eliminate the need for trusting a party. The article has full details on how to create a contract changeable by one party, then hand waving about "writing a contract that uses tokens and voting mechanism to allow the community to decide whether to update or not." No details on how that's supposed to work. Who's "the community", anyway? The parties to the agreement are the ones involved. A mechanism where all parties to a contract could agree to replace it with a new contract would be useful. That's a normal contract activity. You do that whenever you renew a lease. The Etherium promoters want this because they botched the design. Smart contracts as byte coded programs are too error prone. The DAO debacle, and this latest demand for a "state change" because someone botched a big contract, indicate that. Smart contracts should have been in some declarative form like decision logic tables, not Turing-complete programs with race conditions.

CryptoPunk 9y ago
>>The article has full details on how to create a contract changeable by one party, then hand waving about "writing a contract that uses tokens and voting mechanism to allow the community to decide whether to update or not." No details on how that's supposed to work. Who's "the community", anyway? The possibilities are endless. You could have pre-chosen adjucators that can upgrade a contract on majority vote. You could use a decentralized prediction market like Augur to trigger a contract upgrade if it deems that certain events occurred, etc. Upgradability is just one component of many that will be needed to create a durable/secure smart contracting system. It's not a silver bullet. >>The Etherium promoters want this because they botched the design. Do you misspell Ethereum deliberately? I only ask because I've seen you comment multiple times about Ethereum with this misspelling, which comes across as very petty. >>The DAO debacle, and this latest demand for a "state change" because someone botched a big contract, indicate that. The latest state change request is overwhelmingly rejected by the community and will not happen. The request is only possible at all because of the temporary state of Ethereum having several hard forks planned that a state change can be snuck into. Once this phase of its life cycle is over, even requests for a state change will not happen. >>Smart contracts should have been in some declarative form like decision logic tables The point of using byte coded programs and a Turing Complete execution environment is to make features like the smart contract programming language totally configurable, rather tied to a single base implementation.

misrab 9y ago

Maybe consensus should only be reached on certain invariants, with the underlying implementation being far more mutable.