4 ms·

Original author here. I strongly disagree. While it’s certainly true that firmware on many devices can’t be or simply isn’t updated, it’s also the case that bu

Original author here. I strongly disagree. While it’s certainly true that firmware on many devices can’t be or simply isn’t updated, it’s also the case that bugs ship. Because of this, engineers design and ship their more complex devices with the facility to upgrade firmware. Even my ages old stereo receiver is upgradable (although painfully so). But this is about smart contracts: code that in many cases moves money. I’d put that in the category of code that really could benefit from carefully controlled upgradability. I’m not the only one. For instance, the primary USDC contract on Ethereum is a proxy contract — it’s upgradable by design. I think that makes a lot of sense, and apparently so do the engineers managing those many billions of dollars: they’ve weighed the balance of “trust” in the abstract with “make sure it doesn’t break” in the real and made their decision. Beyond that, a guiding principle of some newer blockchains (like Tezos) is that code will need to evolve over time. Like many things Web3, it’s too soon to tell how things will shake out in the long run, and a variety of approaches seems desirable.

sharemywin 5y ago
I think that's what's interesting about "blockchains" versus on specific chain. 1. polygon is a cheap(as in transaction fees) knock off of Ethereum, competition good. bad from the perspective of capture value in the protocol. 2. as far as I can tell as long as one oracle doesn't become dominate that provides competition 3. Defi is enabling users value across other networks. uniswap, etc. 4. On a side note, not sure why there's not an api that encrypts an nft on ipfs and only returns the watermarked version unless you send it a fee. or your the owner.
- toolz 5y ago
  because it's not a real problem. The same way you can buy a mona lisa t-shirt in the gift shop and that doesn't steal any of the value away from the owner. What you describe could be rather easily implemented, but why would anyone build or use that?
  - sharemywin 5y ago
    I guess was thinking like a CDN/istockphoto type marketplace.
serverholic 5y ago
So you deploy a new contract and tell users why they should update. Then they can choose to use the new version or not. I don't think you really understand this idea.
- davepeck 5y ago
  What you’re describing does indeed happen — and in many cases I think it’s a good approach — but it’s not the same as what I’m talking about. You might find these two blog posts useful: 1. OpenZeppelin’s post on the Ethereum proxy pattern: https://blog.openzeppelin.com/proxy-patterns/ https://blog.openzeppelin.com/proxy-patterns/ 2. USDC’s adventure in upgrading their contract: https://blog.coinbase.com/usdc-v2-upgrading-a-multi-billion-dollar-erc-20-token-b57cd9437096 https://blog.coinbase.com/usdc-v2-upgrading-a-multi-billion-...
  - jude- 5y ago
    As a user who might prefer the first version of the code to the second, why should I be excited about a software system that can force me to use the upgraded version? That's a design flaw in the current Web -- when a Web service I rely on changes its behavior and goes out of business, I'm SOL. Web3, with immutable smart contracts that stay online, has the potential to fix this.
toolz 5y ago
Most (any?) smart contract platforms can theoretically bake in a concept of proxy upgrading or even decentralized governance over triggering the proxy into an upgraded contract. Sure it's complex now, but this is still very very new tech and those problems can easily be built upon and abstracted away.
- davepeck 5y ago
  Yes, 100%. It’s one reason why I mentioned Tezos: it has upgradability and upgrade governance built in from day one, which — if nothing else — I think is an interesting design point.
Animats 5y ago
For instance, the primary USDC contract on Ethereum is a proxy contract — it’s upgradable by design. By whom? "Upgrading" a contract should require the approval of all parties to the contract.
- davepeck 5y ago
  Right. In the case of USDC, whoever has the private key to their proxy contract’s owner account. You’re trusting their engineering team to do the right thing. (EDIT: if I’m reading my etherscan correctly, it’s account 0xfcb19e6a322b27c06842a71e8c725399f049ae3a with upgrade rights. Sorry, I’m in transit so tapping on my phone.)
- omarfarooq 5y ago
  USDC is upfront about being centralized.
  - Animats 5y ago
    "Centralized" is not the same as "terms alterable at sole discretion". (Obvious Darth Vader reference).
    - omarfarooq 5y ago
      In the case of USDC, it is: https://www.circle.com/en/legal/us-user-agreement https://www.circle.com/en/legal/us-user-agreement See 25. Amendments.
jude- 5y ago
> I’d put that in the category of code that really could benefit from carefully controlled upgradability. First, if you're saying that you need a way to upgrade your money-managing code periodically because you will likely ship versions of it with show-stopping bugs (such as those that enable the destruction or theft of the users' funds), then why should I trust that you will ship flawless code for upgrades? Second, if the combined security budget of the people who can carry out the upgrade is less than that of the majority of the block producers on the chain, then why build an upgrade procedure at all? Why risk it? Instead, just deploy a new version of the smart contract, and ask users to use that one instead. If it gets confirmed, then an honest majority of block producers will ensure that it stays confirmed. This takes no code at all. You simply sign the new code with the same key that deployed the old code to demonstrate that it originates from the same author(s). Let users decide on their own whether or not to use your upgraded code -- after all, it might introduce new bugs, and the "bugs" you are fixing might be features to other people. It's not your place to tell users what version of the code should be used, and what should not be used.
- davepeck 5y ago
  > why should I trust that you will ship flawless code You shouldn’t, because no code of sufficient complexity is flawless. > just deploy a new version of the smart contract On the Ethereum blockchain (for instance) storage and smart contracts are tightly coupled. If you move to a new smart contract you may well lose your state. This is fine in many cases and preferable in some. But not in others!
  - jude- 5y ago
    > You shouldn’t, because no code of sufficient complexity is flawless. So why build an upgrade procedure at all, when you don't have to? > On the Ethereum blockchain (for instance) storage and smart contracts are tightly coupled. Sounds like an unforced error on these smart contracts' authors parts, and should not be used as an excuse to compromise the principle of code immutability. If the possibility existed that they need to replace the business logic at a later date, then they should factor the storage logic so as to avoid this coupling. It can be done -- for example, a smart contract dapp can leverage a shared contract that only implements a public key/value store, where the keys are prefixed by the calling contract's address. Then, when the business logic contract changes, it can access any old versions' state with the old versions' contract address, apply any migrations on-the-fly, and store new state that will not overwrite old state due to this key prefixing. In the Stacks blockchain (which I work on), we go one step further by making it so you can run an arbitrary read-only code snippet on the state of the blockchain at any point in the past (as given by a block hash). Then, you don't even need to do any migrations -- you can just query the historic state of your old contract and only store new data once it's necessary.

sharemywin 5y ago

I think that's what's interesting about "blockchains" versus on specific chain. 1. polygon is a cheap(as in transaction fees) knock off of Ethereum, competition good. bad from the perspective of capture value in the protocol. 2. as far as I can tell as long as one oracle doesn't become dominate that provides competition 3. Defi is enabling users value across other networks. uniswap, etc. 4. On a side note, not sure why there's not an api that encrypts an nft on ipfs and only returns the watermarked version unless you send it a fee. or your the owner.

toolz 5y ago
because it's not a real problem. The same way you can buy a mona lisa t-shirt in the gift shop and that doesn't steal any of the value away from the owner. What you describe could be rather easily implemented, but why would anyone build or use that?
- sharemywin 5y ago
  I guess was thinking like a CDN/istockphoto type marketplace.

serverholic 5y ago

So you deploy a new contract and tell users why they should update. Then they can choose to use the new version or not. I don't think you really understand this idea.

davepeck 5y ago
What you’re describing does indeed happen — and in many cases I think it’s a good approach — but it’s not the same as what I’m talking about. You might find these two blog posts useful: 1. OpenZeppelin’s post on the Ethereum proxy pattern: https://blog.openzeppelin.com/proxy-patterns/ https://blog.openzeppelin.com/proxy-patterns/ 2. USDC’s adventure in upgrading their contract: https://blog.coinbase.com/usdc-v2-upgrading-a-multi-billion-dollar-erc-20-token-b57cd9437096 https://blog.coinbase.com/usdc-v2-upgrading-a-multi-billion-...
- jude- 5y ago
  As a user who might prefer the first version of the code to the second, why should I be excited about a software system that can force me to use the upgraded version? That's a design flaw in the current Web -- when a Web service I rely on changes its behavior and goes out of business, I'm SOL. Web3, with immutable smart contracts that stay online, has the potential to fix this.

toolz 5y ago

Most (any?) smart contract platforms can theoretically bake in a concept of proxy upgrading or even decentralized governance over triggering the proxy into an upgraded contract. Sure it's complex now, but this is still very very new tech and those problems can easily be built upon and abstracted away.

davepeck 5y ago
Yes, 100%. It’s one reason why I mentioned Tezos: it has upgradability and upgrade governance built in from day one, which — if nothing else — I think is an interesting design point.

Animats 5y ago

For instance, the primary USDC contract on Ethereum is a proxy contract — it’s upgradable by design. By whom? "Upgrading" a contract should require the approval of all parties to the contract.

davepeck 5y ago
Right. In the case of USDC, whoever has the private key to their proxy contract’s owner account. You’re trusting their engineering team to do the right thing. (EDIT: if I’m reading my etherscan correctly, it’s account 0xfcb19e6a322b27c06842a71e8c725399f049ae3a with upgrade rights. Sorry, I’m in transit so tapping on my phone.)
omarfarooq 5y ago
USDC is upfront about being centralized.
- Animats 5y ago
  "Centralized" is not the same as "terms alterable at sole discretion". (Obvious Darth Vader reference).
  - omarfarooq 5y ago
    In the case of USDC, it is: https://www.circle.com/en/legal/us-user-agreement https://www.circle.com/en/legal/us-user-agreement See 25. Amendments.

jude- 5y ago

> I’d put that in the category of code that really could benefit from carefully controlled upgradability. First, if you're saying that you need a way to upgrade your money-managing code periodically because you will likely ship versions of it with show-stopping bugs (such as those that enable the destruction or theft of the users' funds), then why should I trust that you will ship flawless code for upgrades? Second, if the combined security budget of the people who can carry out the upgrade is less than that of the majority of the block producers on the chain, then why build an upgrade procedure at all? Why risk it? Instead, just deploy a new version of the smart contract, and ask users to use that one instead. If it gets confirmed, then an honest majority of block producers will ensure that it stays confirmed. This takes no code at all. You simply sign the new code with the same key that deployed the old code to demonstrate that it originates from the same author(s). Let users decide on their own whether or not to use your upgraded code -- after all, it might introduce new bugs, and the "bugs" you are fixing might be features to other people. It's not your place to tell users what version of the code should be used, and what should not be used.

davepeck 5y ago
> why should I trust that you will ship flawless code You shouldn’t, because no code of sufficient complexity is flawless. > just deploy a new version of the smart contract On the Ethereum blockchain (for instance) storage and smart contracts are tightly coupled. If you move to a new smart contract you may well lose your state. This is fine in many cases and preferable in some. But not in others!
- jude- 5y ago
  > You shouldn’t, because no code of sufficient complexity is flawless. So why build an upgrade procedure at all, when you don't have to? > On the Ethereum blockchain (for instance) storage and smart contracts are tightly coupled. Sounds like an unforced error on these smart contracts' authors parts, and should not be used as an excuse to compromise the principle of code immutability. If the possibility existed that they need to replace the business logic at a later date, then they should factor the storage logic so as to avoid this coupling. It can be done -- for example, a smart contract dapp can leverage a shared contract that only implements a public key/value store, where the keys are prefixed by the calling contract's address. Then, when the business logic contract changes, it can access any old versions' state with the old versions' contract address, apply any migrations on-the-fly, and store new state that will not overwrite old state due to this key prefixing. In the Stacks blockchain (which I work on), we go one step further by making it so you can run an arbitrary read-only code snippet on the state of the blockchain at any point in the past (as given by a block hash). Then, you don't even need to do any migrations -- you can just query the historic state of your old contract and only store new data once it's necessary.