"mostly" being the key word :) If you're self-hosting, then your server is a weak point. It goes down, your app goes down. The additional cost and risk that comes with using blockchains provides a platform for your app to run on that you don't have to manage and is highly resistant to being shut down.

Likewise, there always exists the possibility that your server can be compromised and the code can be altered. The immutability of the blockchain guarantees that your code cannot be changed, with or without your knowledge.

You pay a lot for that blockchain redundancy. You can buy a lot of conventional redundancy for that money. Comparing it to a cheap self-hosted server isn't apples to apples.

> The immutability of the blockchain guarantees that your code cannot be changed, with or without your knowledge.

There's been a lot of examples lately why this is not a desirable feature at all for most purposes.

Correct me if I'm wrong, but isn't a dapp dependent on sufficient mining/distributed compute being in the network?. Of the network becomes small can someone attack it and change past transactions/hijack apps?

Yes, these are the failure scenarios I had in mind when I wrote "the ability to shutdown these apps would rely on somehow breaking the blockchain itself".

It's possible that bugs in the blockchain software can cause blocks to no longer be produced, essentially halting the network until the problem is resolved. So-called 51% attacks are also a failure possibility.

I'd suspect that the longevity of a cloud provider or self hosted environment would be higher than the time miners are willing to support a new block chain (I'm not paying a btc transaction fee everytime I update an app).

How will miners be paid to host apps? Given that app usage concentrates into winner take all groupings wouldn't we except the web 3 winners to be paying for the vast majority of any web 3 mining?

You're getting to a fundamental issue that separates Bitcoin from other chains which strive to push and hold more data on chain: there is no efficient pricing mechanism to host data. What this means is that putting any data on chain at all is either expensive, or limited by hard code. The issue is that the data stays on chain forever yet without any 'rent' associated to it, therefore space is limited or cost is poorly estimated up front (or compromises on decentralization like sharding occur).

Bitcoin doesn't technically solve this either, its just that its data growth rate is small enough to be trivial in comparison to storage costs. Ethereum and other classical distributed ledger systems cannot fulfill the true vision of Web3 (it can and will continue to do a fraction of that vision) because they have no affectual economic functions for data rent or data handling in general. Mining/staking is paid for and everything else is an economic after-thought. Ethereum's Infura Problem is a quick way to see the consequences of these poorly suited economic incentives.

Bitcoin is about stability, but Web3 is about data, so I believe its fair to say that a distributed ledger technology built for "Web3" (which is quickly becoming a dirty word) will have its economic components focused on data. This is different from keeping the traditional Nakamoto Consensus (which judges value based on somewhat arbitrary measures) but deriving tricks to push more data - this means maintaining or exceeding the security guarantees of Nakamoto Consensus while incentivizing data routing-work and storage rather than number crunching.

Miners don't host the front ends. Miners run whatever contract code is called by anyone who sends a signed transaction.

Wouldn't actions like add to cart, etc all require contract code execution?

There are easy mitigations for those things though. My self hosted apps run on immutable infrastructure and are replicated and load balanced. Still stupid cheap and easy.

> My self hosted apps run on immutable infrastructure and are replicated and load balanced

What? Assuming you live in the US, the government can swoop in at any time (provided they have a legal reason to do so) and demand that AWS or whoever's hosting your servers shuts them down. If you're hosting them yourself, they can raid the physical locations where you host them. If you're not in the US, I'm sure your country has equivalent security forces that would be more than capable of doing the same should the government find a reason to.

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

Also, you didn't address code immutability guarantees. You can change your server code at any time and your users would be none the wiser. The darknet markets, once compromised by federal agents, did exactly this, and stopped actually encrypting user messages with PGP while continuing to pretend to do so. A smart contract, unless it has upgradeability built in, offers just this sort of guarantee to its users.

Oh, and if your app deals with finance, and the US government (or your own) wants you to stop letting John Doe use your app because they just placed new sanctions on Mr. Doe? You'd better code that compliance feature up real quick or see yourself getting heavily fined or even imprisoned. Tough luck doing that sort of censorship on the blockchain -- as long as a single miner is willing to include that user's transaction, they're basically in.

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

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.

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

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

How does your local hosted setup move value/money in a way that others trust it?

But no one else can use your app with the same guarantees you give to yourself, while also being able to share state with you.

Is that true though? If two people run self hosted apps that can communicate, all you have to verify is the data passing between. What assurances are you missing?

They can communicate, but if they want to agree on shared state between them, they have to solve the same problem that blockchains seek to solve, and the options available to you there are essentially on a spectrum of how many people are going to participate and to what extend you can vet them.

I don’t think multiplayer games are running a blockchain and they agree on shared state. Humans being humans tend to reject cheaters who manipulate the state in their favor. But you don’t need a blockchain for any of this, and in fact, it’s too slow to have shared state /in real time/.

While I'm not really big on "Blockchain all the things!" this might be a poor analogy, considering just how many big multiplayer games use very intrusive, almost rootkit level anticheat software to, effectively, try and force all clients to behave and share state fairly...

Hmm. Might be a poor analogy then. I’ve never had any issues with anti-cheat software or ever noticed it’s existence — other than an icon on a splash page.

Not really; it is the server that tells all clients what the state is.

I know "there is nothing new that blockchain does" has become a meme among sceptics, but with respect, I am getting a bit tired of it.

It's just not accurate. You can argue that what the way blockchain allows for shared state is useless all they long, or that the financial use cases are undesirable, and that's all fine. But you simple cannot run the kind of apps that are running on Ethereum right now, enabling financial transactions, with the same guarantees of décentralisation and permissionless access, w/o a blockchain.

It may be useless and/or criminal, but it is certainly new and it works.

> Not really; it is the server that tells all clients what the state is.

Not with realtime action games, nope. The server hopefully verifies, but not even that is a given... Just look at New Worlds immortality bug from a few weeks back for a pretty large budget game that forgot to do that to a sufficient degree.

Thanks for the heads-up. Sounds like I don't know enough about how those games are made.

I’m not arguing that the blockchain isn’t valuable. I think it does unlock new and interesting things. I think we are still learning what those things are, outside of crypto transactions. And like anything else, there’ll be times to apply it and times not.

Looks like you are describing the value of the distributed non-permissioned consensus mechanism, without using those words.

Dude the internet is made of protocols that accomplish “shared state”

Ever heard of dns or IP addresses?

What about bittorrent, tor, i2p, ipfs?

If blockchain is more expensive than cloud for you, the person that launched the product, then you architected your project wrong

Blockchain products are write once, read free, persist forever for free.

Your users pay to interact. Every SaaS funnel person knows that of you get users to pay at all then you have filtered the funnel to larger payments already. Blockchakn projects are that funnel in warp speed.

I disagree. The cost of just deploying my contract might pay for years of self hosting at current transaction rates. It might eventually amortize out to cheaper over many, many years, but that assumes no changes are ever needed. How likely is that?

You could use any other EVM or smart contract platform than Ethereum

zkEVM

The person you're replying to has already addressed your points:

> Yes, blockchains are slower and more expensive. This is the current cost of enabling the two facets above. If we're not comparing blockchain dapps to other systems that offer the same assurances, then we're comparing apples and oranges.

Could you please respond more meaningfully to the conversation?

I thought I did... That quoted paragraph doesn't negate my point which is that I do get the same (or very similar) assurances elsewhere, so I think the comparison is valid.

Ah my bad, I thought you were focusing on the features rather than the assurances. I'll respond to the other comment you made.

To me the two words (feature and assurance) are synonyms in this discussion. I meant both above.

They didn't address the points - they tried to say nobody gets to compare other things unless they do <the two facets that dapps offer>. Which is wrong.

They said it's an apples to oranges comparison unless both things do <the two facets that dapps offer>. Which is absolutely correct. You could compare apples to oranges if you wanted to... but usually there's no point in doing so.

As I said to OP, no, it's not apples to oranges, you are absolutely wrong. It's comparisons of different points in the app architecture space, and that's normal, and not pointless as you claim.

You can't wave away the serious issues by saying "there's no point in comparing them"

Lots of things offer different functionality and tradeoffs. If you want to play in the space of "web app", you can and should be compared to things that are solutions for producing "web apps". We compare codeless web apps to code ones, etc.

The same way people compare gas and electric vehicles. Or minivans and suvs and trucks. Or, well, everything in a solution space.

Any solution for a given use case can and should get compared with other solutions for that use case.

I'm really sorry that it doesn't seem (judging by this thread) to compare particularly well for most developers, but that doesn't invalidate the comparison.

> Any solution for a given use case can and should get compared with other solutions for that use case.

And the current use cases are sufficiently different that it's like comparing apples and oranges.

> I'm really sorry that it doesn't seem (judging by this thread) to compare particularly well for most developers, but that doesn't invalidate the comparison.

Again, do you think the same of Tor? It doesn't compare particularly well by most mainstream metrics. High latency, low bandwidth. And yet it serves a lot of value to a lot of people.

But then some smartass goes and says "It's completely useless tech, I can host a simple static website on clearnet for much less hassle." Yeah, duh, but that's not the point of Tor. Go use the clearnet if that's what you're looking to do.

"And the current use cases are sufficiently different that it's like comparing apples and oranges."

Uh, what? This whole thread and post is about the argument that replacing existing apps with dapps will be better (or worse).

No, this particular thread started by v64 is precisely that comparing existing apps on the regular web to dapps is comparing apples and oranges. The use cases and guarantees are pretty darn different.

Again, no.

They specifically said that it has advantages over current apps, and compared what happens with your current apps when you don't pay your AWS bill.

They then later, after lots of comments pointing out that nobody cares, said "well you can't really compare it to any of those things".

You seem more sane in the sense of what you think this stuff will do.

If this is how my position came across, it wasn't my intent and I'll clarify.

Immutability and resistance to shutdown are not features that the vast majority of apps, present and in the future, will ever need. My main dispute with the original article is that the author argues every single use case of a Web3 app can be done with a traditional app, and I argue that's simply not true. The case where that breaks down is precisely when your app requires immutability and resistance to shutdown.

To use an analogy: Most people will never need to own or use an armored car, and if you evaluated an armored car based on its viability as a consumer vehicle, you would say that its fuel requirements and maintenance costs are impractical, because you don't need the assurance of having a bulletproof vehicle in your everyday life. It would be overkill.

Similarly, these Web3 technologies are not being designed to replace YouTube or Facebook. If you're building a service like that, you don't need the armored car. On the other hand, if you're designing an app that performs financial transactions, then the armored car may be something you can use. Or not! But the option is there.

99% of developers will never need to build an app this way. But there are use cases outside of ponzi schemes and fraud that seem to be overlooked and which I think are worth drawing attention to.