I get mostly the same features with self-hosted and local traditional apps for a fraction of the price and much lower general financial risk as well.
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.
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.
I'm my only user, that's why I'm discussing self-hosted apps here...
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.
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.
Also, just use a friggin VPN.
How would you propose to ban all cryptos? We haven't even been able to ban torrents.
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.
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.
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?
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.
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.
You can do all that, but then who but the most gullible will use your smart contracts?
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
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.
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.
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.
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.
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.
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?
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.
> 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.
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 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.
Ever heard of dns or IP addresses?
What about bittorrent, tor, i2p, ipfs?
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.
> 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?
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.
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.
Uh, what? This whole thread and post is about the argument that replacing existing apps with dapps will be better (or worse).
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.
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.