Hacker News Reader

Comment by vmception | Hacker News Reader

Can you elaborate? None of these Virtual Machines go away because so many people run them and can run them, including yourself. You can branch off the current state or any prior state and run/execute it locally at any point in time, without needing the resources to run the whole blockchain. This is enough for you and your community/clients to have the data to move it all somewhere else, if necessary. If you need all the prior states for some reason, someone will have it for you to bootstrap from. What would stop working?

and when you mean latest scam ... how? all - or all major - blockchains have had this feature since day 1. reading is free, writing is not. now all the nodes in most networks can function as event-driven compute services, similar to aws lambda and other products, except reading and bandwidth is free.

View on HN

The amount of storage is not unlimited. The amount of goodwill from the nodes is not unlimited. The value of ethereum is not unlimited. The amount of reads can easily be “played with”

Thanks for coming to this thread, I'm curious what the other person meant though.

Yes, there is a stack and heap limiting the amount of resources that a command can use. So what? Design your application with that limitation in mind. Focus on what you can control, its a one-step one-click funnel that is inherently a payment and insatiable demand right now from the users. A Web 2.0 dream, I've sat through so many useless OKRs and KPIs meetings trying to figure that out, and now its just here for any individual willing to look, apply the same concepts and use it.

What do you mean about the amount of reads can be played with? I don't see how it matters. You can read the state of a smart contract or any account for free. Not really sure how this is a point.

I didn’t understand you.

But, imagine a DDOS attack on the nodes serving the blockchain. I don’t see why “pay once read forever” works financially.

> But, imagine a DDOS attack on the nodes serving the blockchain.

Okay.

> I don’t see why “pay once read forever” works financially.

A separate issue thats not really your problem. Its the node operators problem. When your use case expands to that being a viable problem for you, then you'll need to become a node operator or at least keep a copy of the state yourself. You can design applications around that. Or maybe you can't. Just rule those out or keep using AWS or some other company for those applications?

>Focus on what you can control, its a one-step one-click funnel that is inherently a payment and insatiable demand right now from the users

right now is the really, really big issue here. We're talking about pay once read forever, not pay once read right now, or pay once and read while there's still interest or demand in running nodes.

Can you elaborate on what your concern/criticism/cynicism is?

What use case are you trying to imagine?

I think its been very easy and very competitive to design applications around using these redundant blockchain nodes as event-driven compute nodes, when compared to AWS Lambda or even addons to a paid Vercel plan or hosting my own microservice somewhere. The uptime has been on-par and the system design gives some assurances of the ability to maintain the uptime where it could theoretically be a concern.

They go away when people stop running them or the system fails to function which is not forever but sometime in the future.

It is a scam to promise forever. AWS doesn't promise forever. It's free reads until one day.

got it. okay. you can make a backup and continue executing in a smaller environment even if the rest of the network falls apart. I feel like that would be really hard to do with like AWS Lambda. Altneratively you can have just enough information to store the last relevant state and migrate to another system.

in the meantime you won't be charged for how much you read or how often. which was my main point. before this conversation, did you know that?

Reply on news.ycombinator.com