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.

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

> Good luck raiding every single Ethereum node in the world to take down a smart contract.

They won't have to. It's like putting absurd security on your door yet leaving the windows as open as always.

If you ever want to move value out of your virtual economy and into the real, they can and will be there waiting for you, with all their unreasonable demands.

That introduces more friction into the process, but incentives will always find a way. We haven't been able to stop a billion dollar drug trade, what makes you think banning a trillion dollar crypto market will cause it to disappear entirely? It might have a huge collapse in value and finally drive away all the dumb money pouring in, but it will still be there.

> Good luck raiding every single Ethereum node

I’m just waiting for the day when governments decide that all this crypto is hurting the environment more than necessary for no real gain and forces ISPs to block this traffic. Similar to how many ISPs block serving DNS or SMTP from residential IPs.

Then that'll be the day proof of stake cryptos rise to the occasion.

Also, just use a friggin VPN.

IMHO, VPNs scare me more than ISPs spying on me. I ran a small ISP (<100 subscribers) and the sheer amount of data you could collect on a single person was mind boggling. This was pre-https-all-the-things, so I’m sure it’s better these days. Still, do I really want my traffic to go through some unregulated entity? Not really…

Hah! That's fair. I'm just saying, if you still wanted access to your crypto assets after the ban, they should likely still be quite accessible.

How would proof of stake mitigate ISP blocks? These still communicate with other nodes over TCP/IP.

The fantasy of the block being rolled back because now they're doing something different.

Given the comment I was responding to, I was assuming that only a ban would be attempted on the environmentally unfriendly cryptos.

How would you propose to ban all cryptos? We haven't even been able to ban torrents.

I believe it is possible to ban them, with a combination of multinational regulation and technical coordination with ISPs. Not easy nor even likely.

ISPs could simply run honeypots that in real time sniff out who is running a blockchain node and block traffic to those IPs. These nodes must broadcast publicly to other nodes to even function, so they can't hide the fact that they are a blockchain node: they are forced to peer with whoever else is... peering in the same direction, pun intended.

I'd love to know what gaps in my knowledge invalidate the above thesis, though.

Is the same not true of torrents?

The difference being that torrents only have ISPs sending out DMCA notices for violators, not shutting off their internet.

Well okay, I mean if you go all out North Korea, I suppose it's possible to ban crypto in your country.

So we're agreed it is technically possible. Technically as in code.

> You can change your server code at any time and your users would be none the wiser.

I'm my only user, that's why I'm discussing self-hosted apps here...

Ah, natural language. I'd interpreted you as meaning that you host the apps yourself rather than let someone do it for you (hence "self-hosting"), and you host these apps for others to use.

I mean, yes, but if your use case is only yourself as the sole user, that's quite different from the majority of businesses out there who need to service many users. This is truly like comparing apples and oranges.