Hacker News Reader

Comment by uncomputation | Hacker News Reader

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

View on HN

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

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.

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.

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.

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).

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

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.

> 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

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.

> The contract developer releasing the code is the problem, not verifying that is what is running.

In a trustless environment like defi, why would anyone other than the most gullible put their money in any smart contract that doesn't have open sourced code?

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

We assume and trust because we have to. With crypto, you can trust and verify, as the Russians say.

> In a trustless environment like defi, why would anyone other than the most gullible put their money in any smart contract that doesn't have open sourced code?

So... this is a thing for techies only? The rest of the world that can't read the code will have to trust the techies that say "this is good".

As a not-JavaScript-devleoper, open sourced optimal written JavaScript is only slightly less inscrutable than minified or compiled JavaScript.

So, would I be gullible to put my money into a smart contract written in JavaScript?

Most of the world can't verify the code and will need to trust someone. I hope that isn't the password verification commission that calls grandmothers offering to help check out their bank account security.

> Most of the world can't verify the code and will need to trust someone.

I haven't scrutinized the code for major flagship apps like Uniswap either. But plenty of others have, including paid auditors.

With open-sourced code, you can actually do this. You can actually get semi-reliable signals that others have scrutinized the code and found it to be fine. Not completely reliable, because sometimes auditors also miss subtle exploits. But you know, everyone's risk tolerance is different. Decide for yourself what degree of trust you're comfortable with, and put or don't put your money in accordingly.

This isn't specific to crypto, this is true for open source in general.

> So... this is a thing for techies only? The rest of the world that can't read the code will have to trust the techies that say "this is good".

But yes, as of now pretty much. The average Joe who cannot remember their own passwords should not be using crypto, IMO. With freedom comes the freedom to shoot yourself in the foot, and unless you understand basic digital safety procedures, you are best off not shooting yourself in the foot.

Reply on news.ycombinator.com