But, now you have a stateful application running in the cloud, vs an immutable blockchain. And that implicitly means you are now trusting authoritative nodes to hold that state. This is basically moving closer and closer to just a bunch of nodes running a database with some consensus mechanism, rather than an actual blockchain.
(I'm not personally sold that this is actually a distinction that matters - after all, we are already implicitly trusting "authoritative nodes" to deliver the blockchain, and the same mechanism that prevents alteration of the blockchain right now would also prevent altering the database state. Namely, that nobody else is going to accept the version of history where I own infinity bitcoins, regardless of how we record that state.)
A middle ground might be to have the full state available to nodes that want to verify, but also implement a "checkpoint/epoch" mechanism on top for "fast clients" who aren't overly concerned about a massive concerted-but-silent attack on Bitcoin escaping notice.
It's not THAT hard to run a full node, even with 32MB blocks. But for people that want to kickstart a local node, they don't need the entire history if there's a trusted checkpoint mechanism. So they can participate, validate new blocks coming in, while they never or slowly download the historical blockchain.
A hash chain of every block is only a few MB so it's not that big of a deal to make sure the chain is immutably stored.
> It's not THAT hard to run a full node, even with 32MB blocks.
Not at present, but if you increase the block size then you ramp that up pretty fast. Let's say there's a block every 9 minutes (nominally 10 but the network is reactive to increased hash power so it's a bit less in reality). That's 58400 blocks per year, which with a 32 MB block size would translate to 1,868,800 MB per year.
A growth rate of 2 TB per year would very quickly take you past the point where "anyone can have a copy". Yes, it would still be feasible for power-users who could dedicate a whole HDD or some NAS space to it, but that's implicitly conceding the whole "anybody can have a copy" point, and the growth would still be continuing unabated.
And the problem is - Bitcoin's transaction rate is currently so slow that 32 MB is not really a big enough block size. Going from 7 tx/sec to 224 tx/sec is still pitiful for a global network, again Visa does 50k tx/sec at peak.
I agree that it seems highly plausible that some form of "checkpointing" mechanism could be securely implemented.
In fact if you "trust the network" then there's no reason to download the blockchain at all, you can run the Electrum client. And if you think all the nodes are lying to you... how do you ever get the blockchain securely in the first place, regardless of a checkpoint mechanism?
Power users that could dedicated a $50 drive? Storage just keeps getting cheaper. Bandwidth is more likely to be a limiting factor. But looking at dedicated servers, $50/mo gets you 8TB of disk + plenty of bandwidth.
Checkpointing cannot be hard. The hashes of 58400 blocks is not even 2MB. So with a few dozen megs you can checkpoint every single block. Then you can download blocks on-demand if you need to find particular transactions or whatever. What is really lost if we tossed the previous blocks after a year and just kept balances?
(I'm not personally sold that this is actually a distinction that matters - after all, we are already implicitly trusting "authoritative nodes" to deliver the blockchain, and the same mechanism that prevents alteration of the blockchain right now would also prevent altering the database state. Namely, that nobody else is going to accept the version of history where I own infinity bitcoins, regardless of how we record that state.)
A middle ground might be to have the full state available to nodes that want to verify, but also implement a "checkpoint/epoch" mechanism on top for "fast clients" who aren't overly concerned about a massive concerted-but-silent attack on Bitcoin escaping notice.