4 ms·

> code immutability guarantees Phrased another way, “bug immortality guarantees.” What is the use case for completely immutable software? Even Ethereum smart c

> code immutability guarantees Phrased another way, “bug immortality guarantees.” What is the use case for completely immutable software? Even Ethereum smart contracts do not actually guarantee the compiled byte code matches the supposed source of the contract, so while it might be immutable, it is not free. I think the bigger concern is not that the code will update - updates are good, especially ones for bug fixes like the log4j vulnerability recently - but that the code they say is running, is not actually running. And let’s assume that we need to update our code. You need to pay to deploy an entirely new contract and then have some sort of “pointer”/gateway that redirects all your users to the new patched contract, and then we’re right back where we started where this gateway can be forced by law to not direct people to your contract much like Google can be DMCA’d to not show copyright violations.

selestify 5y ago
> Even Ethereum smart contracts do not actually guarantee the compiled byte code matches the supposed source of the contract What? You don't have to publish your smart contract code for the public to verify, but you absolutely can. And once you do, the public can absolutely verify that the smart contract code you provided does in fact compile to the byte code deployed to the blockchain. > and then we’re right back where we started where this gateway can be forced by law to not direct people to your contract much like Google can be DMCA’d to not show copyright violations. You don't have to include that upgrade functionality in your smart contracts. Or if you do include upgrade functionality, you can limit what sort of functionality can be upgraded. Otherwise, yes, it's no different than just running your own server and changing the code all of a sudden with the users being none the wiser. Question is, if you don't limit your upgrade functionality, are your users going to trust you not to rugpull?
- uncomputation 5y ago
  Given that you can deploy smart contracts as binaries (without source) and you can design the contracts to be upgradeable if needed, I don’t see any advantages of this system. Sure, the contract can be immutable but the only advantage is for the archivist who now has a permanent record of the software history. Other than a public change log, this doesn’t have much utility.
  - miracle2k 5y ago
    It's up to you to decide how much control over your smart contract and it's assets you want to put into who's hands. It reasonable that the EVM would want to account for a wide range of use-cases. The point is simply to be able to make certain immutability guarantees, if you do want them. The utility is very evident in that something like a Uniswap pool a) works and b) cannot be stopped, so people who do find a Uniswap pool useful, are able to rely on the guarantees made by the smart contract, including of course any potential bugs.
    - uncomputation 5y ago
      It seems you’re talking from the developer’s point of view, the person who writes and deploys smart contracts. I am coming from the end user’s point of view, who has very little to gain from the immutability guarantees. For Uniswap pools, you’re referring to smart contracts that allow people to take out or provide funding for loans, right? So the immutability of the contract may be appealing in terms of interest rates or loan duration/terms/etc. But this option already exists outside of DeFi (fixed rate loans). It is cool that we can offer these in a decentralized manner, but the possibility of a bug affecting my mortgage or another sizable loan is a huge, huge deterrent and I am also sure that, if DeFi “takes off,” there will be solutions implemented that completely remove all immutability guarantees.
      - lottin 5y ago
        Immutability is the least of DeFi's problems. A DeFi "loan" requires that the borrower must put up an amount equal to the sum of all future installments... which means for a borrower to be able to borrow funds they need to already have the funds they're borrowing (plus interest).
  - selestify 5y ago
    > Given that you can deploy smart contracts as binaries (without source) and you can design the contracts to be upgradeable if needed You can do all that, but then who but the most gullible will use your smart contracts?

selestify 5y ago

> Even Ethereum smart contracts do not actually guarantee the compiled byte code matches the supposed source of the contract What? You don't have to publish your smart contract code for the public to verify, but you absolutely can. And once you do, the public can absolutely verify that the smart contract code you provided does in fact compile to the byte code deployed to the blockchain. > and then we’re right back where we started where this gateway can be forced by law to not direct people to your contract much like Google can be DMCA’d to not show copyright violations. You don't have to include that upgrade functionality in your smart contracts. Or if you do include upgrade functionality, you can limit what sort of functionality can be upgraded. Otherwise, yes, it's no different than just running your own server and changing the code all of a sudden with the users being none the wiser. Question is, if you don't limit your upgrade functionality, are your users going to trust you not to rugpull?

uncomputation 5y ago
Given that you can deploy smart contracts as binaries (without source) and you can design the contracts to be upgradeable if needed, I don’t see any advantages of this system. Sure, the contract can be immutable but the only advantage is for the archivist who now has a permanent record of the software history. Other than a public change log, this doesn’t have much utility.
- miracle2k 5y ago
  It's up to you to decide how much control over your smart contract and it's assets you want to put into who's hands. It reasonable that the EVM would want to account for a wide range of use-cases. The point is simply to be able to make certain immutability guarantees, if you do want them. The utility is very evident in that something like a Uniswap pool a) works and b) cannot be stopped, so people who do find a Uniswap pool useful, are able to rely on the guarantees made by the smart contract, including of course any potential bugs.
  - uncomputation 5y ago
    It seems you’re talking from the developer’s point of view, the person who writes and deploys smart contracts. I am coming from the end user’s point of view, who has very little to gain from the immutability guarantees. For Uniswap pools, you’re referring to smart contracts that allow people to take out or provide funding for loans, right? So the immutability of the contract may be appealing in terms of interest rates or loan duration/terms/etc. But this option already exists outside of DeFi (fixed rate loans). It is cool that we can offer these in a decentralized manner, but the possibility of a bug affecting my mortgage or another sizable loan is a huge, huge deterrent and I am also sure that, if DeFi “takes off,” there will be solutions implemented that completely remove all immutability guarantees.
    - lottin 5y ago
      Immutability is the least of DeFi's problems. A DeFi "loan" requires that the borrower must put up an amount equal to the sum of all future installments... which means for a borrower to be able to borrow funds they need to already have the funds they're borrowing (plus interest).
- selestify 5y ago
  > Given that you can deploy smart contracts as binaries (without source) and you can design the contracts to be upgradeable if needed You can do all that, but then who but the most gullible will use your smart contracts?