4 ms·

> 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 upgra

by 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.
  - davepeck 5y ago
    > So why build an upgrade procedure at all, when you don't have to? Flaws, once known, can be remediated. I don’t think macOS has bulletproof security but I’m sure glad Apple keeps updating it. > 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). That’s a super interesting design point; I’m excited to see where that leads. Out of curiosity, how does this typically get exposed in dApps (or wallet UIs) built on Stacks?
    - jude- 5y ago
      > Flaws, once known, can be remediated. I don’t think macOS has bulletproof security but I’m sure glad Apple keeps updating it. My point is that a piece of software does not need an upgrade procedure if there exists a way to install a newer copy without touching the old one. Trying to build an upgrade procedure when there is always the option to install a newer version this way (especially if it can seamlessly access the older version's state) is at best over-engineering. > Out of curiosity, how does this typically get exposed in dApps (or wallet UIs) built on Stacks? This is being done right now with Stacks' on-chain naming system, which is realized as a smart contract. The new naming system does not need to import any state from the old system in order to resolve pre-existing names, nor does the existing naming system need to be disabled, because the new system is instead able to call the name resolution method via this "run read-only code on the chainstate as of this block" feature. The past is immutable, so future changes to the state of the old system beyond a predetermined sunset block (defined in the new contract) will not be visible to the users of the new system. Consider this example. Suppose the name "alice.btc" was registered at block 1000 (hash 0x123) in the old system, and suppose the new system was deployed to use all the state in the old system up to block 1001 (hash 0xabc). Resolving alice.btc in the new system runs code to the effect of: (let ( (alice-rec (at-block 0xabc (contract-call? 'SP000000000000000000002Q6VF78.bns name-lookup? "alice.btc"))) ) ;; Do something with alice-rec ) Internally, the (at-block) function runs the given code body with access to the system state as it was as of the end of block 0xabc. The system state is represented internally as a set of key/value pairs indexed by a forest of authenticated hash tries which make it efficient to query a key as of a particular block (see https://github.com/stacksgov/sips/blob/main/sips/sip-004/sip-004-materialized-view.md https://github.com/stacksgov/sips/blob/main/sips/sip-004/sip... for details). Suppose bob.btc was registered in block 1002 (hash 0xdef). The above (at-block) call will not resolve bob.btc in the old contract, because its state was written after the sunset block 0xabc.
frazbin 5y ago
> 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. I can't see how the operation you describe here is defined or possible for any blockchain that hosts more than one smart contract. Just for a start, how do you decide whether to include a smart contract upgrade that the majority of verifiers doesn't care about either way (surely the most common case)? It's like saying that legislation doesn't matter because we have elections. The elections (consensus) produce the legislation (allowed transactions). You can squish those two layers together, but starts to break the premises of the underlying system (e.g. DAO fork). I would love to know what software system you were thinking of when you wrote this. Or were you? Sincere question.
- aspenmayer 5y ago
  Uniswap comes to mind. V2 is superseded by V3, and V3 is the default option of the web UI, but you can still use V2. There are no plans to sunset V2, and I’m not certain that V2 could be terminated at this point, as the signing keys were burned IIUC.

by jude- 5y ago

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.
- davepeck 5y ago
  > So why build an upgrade procedure at all, when you don't have to? Flaws, once known, can be remediated. I don’t think macOS has bulletproof security but I’m sure glad Apple keeps updating it. > 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). That’s a super interesting design point; I’m excited to see where that leads. Out of curiosity, how does this typically get exposed in dApps (or wallet UIs) built on Stacks?
  - jude- 5y ago
    > Flaws, once known, can be remediated. I don’t think macOS has bulletproof security but I’m sure glad Apple keeps updating it. My point is that a piece of software does not need an upgrade procedure if there exists a way to install a newer copy without touching the old one. Trying to build an upgrade procedure when there is always the option to install a newer version this way (especially if it can seamlessly access the older version's state) is at best over-engineering. > Out of curiosity, how does this typically get exposed in dApps (or wallet UIs) built on Stacks? This is being done right now with Stacks' on-chain naming system, which is realized as a smart contract. The new naming system does not need to import any state from the old system in order to resolve pre-existing names, nor does the existing naming system need to be disabled, because the new system is instead able to call the name resolution method via this "run read-only code on the chainstate as of this block" feature. The past is immutable, so future changes to the state of the old system beyond a predetermined sunset block (defined in the new contract) will not be visible to the users of the new system. Consider this example. Suppose the name "alice.btc" was registered at block 1000 (hash 0x123) in the old system, and suppose the new system was deployed to use all the state in the old system up to block 1001 (hash 0xabc). Resolving alice.btc in the new system runs code to the effect of: (let ( (alice-rec (at-block 0xabc (contract-call? 'SP000000000000000000002Q6VF78.bns name-lookup? "alice.btc"))) ) ;; Do something with alice-rec ) Internally, the (at-block) function runs the given code body with access to the system state as it was as of the end of block 0xabc. The system state is represented internally as a set of key/value pairs indexed by a forest of authenticated hash tries which make it efficient to query a key as of a particular block (see https://github.com/stacksgov/sips/blob/main/sips/sip-004/sip-004-materialized-view.md https://github.com/stacksgov/sips/blob/main/sips/sip-004/sip... for details). Suppose bob.btc was registered in block 1002 (hash 0xdef). The above (at-block) call will not resolve bob.btc in the old contract, because its state was written after the sunset block 0xabc.

frazbin 5y ago

> 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. I can't see how the operation you describe here is defined or possible for any blockchain that hosts more than one smart contract. Just for a start, how do you decide whether to include a smart contract upgrade that the majority of verifiers doesn't care about either way (surely the most common case)? It's like saying that legislation doesn't matter because we have elections. The elections (consensus) produce the legislation (allowed transactions). You can squish those two layers together, but starts to break the premises of the underlying system (e.g. DAO fork). I would love to know what software system you were thinking of when you wrote this. Or were you? Sincere question.

aspenmayer 5y ago
Uniswap comes to mind. V2 is superseded by V3, and V3 is the default option of the web UI, but you can still use V2. There are no plans to sunset V2, and I’m not certain that V2 could be terminated at this point, as the signing keys were burned IIUC.