4 ms·

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

> 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?
  - uncomputation 5y ago
    The point I am making is every smart contract is Schrodinger’s contract where the user has no idea what is inside and no way to know. Say you have a game called, I don’t know, Crypto Run. To purchase in game assets, the developers of Crypto Run deployed a smart contract that lets players do this. You have to use the smart contract from the developers and even if alternatives exist, people want to use the official contract from the development team. There is nothing stopping the Crypto Run team from sneaking in some telemetry code and we have to trust that they don’t. So we’re back to a trust-dependent system.
    - selestify 5y ago
      > The point I am making is every smart contract is Schrodinger’s contract where the user has no idea what is inside and no way to know. I literally explained a few comments ago how that's not the case. Did you forget what you read already? https://news.ycombinator.com/item?id=29588550 https://news.ycombinator.com/item?id=29588550
      - uncomputation 5y ago
        The contract developer releasing the code is the problem, not verifying that is what is running. When a company open sources some code, we assume and trust they are not keeping a separate, evil branch running in production unbeknownst to us. If Facebook “open-sourced” their entire platform and infrastructure tomorrow, the hard part is not verifying that this code is what is running. The hard part would be getting Facebook to do this in the first place. Your use case (of the developer open sourcing their code already) is not the hard part.
        deleted 5y ago

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?
- uncomputation 5y ago
  The point I am making is every smart contract is Schrodinger’s contract where the user has no idea what is inside and no way to know. Say you have a game called, I don’t know, Crypto Run. To purchase in game assets, the developers of Crypto Run deployed a smart contract that lets players do this. You have to use the smart contract from the developers and even if alternatives exist, people want to use the official contract from the development team. There is nothing stopping the Crypto Run team from sneaking in some telemetry code and we have to trust that they don’t. So we’re back to a trust-dependent system.
  - selestify 5y ago
    > The point I am making is every smart contract is Schrodinger’s contract where the user has no idea what is inside and no way to know. I literally explained a few comments ago how that's not the case. Did you forget what you read already? https://news.ycombinator.com/item?id=29588550 https://news.ycombinator.com/item?id=29588550
    - uncomputation 5y ago
      The contract developer releasing the code is the problem, not verifying that is what is running. When a company open sources some code, we assume and trust they are not keeping a separate, evil branch running in production unbeknownst to us. If Facebook “open-sourced” their entire platform and infrastructure tomorrow, the hard part is not verifying that this code is what is running. The hard part would be getting Facebook to do this in the first place. Your use case (of the developer open sourcing their code already) is not the hard part.
      - deleted 5y ago