|
|
|
|
|
by frazbin
1669 days ago
|
|
Being able to query arbitrary past blockchain history is kind of gross, because you can neither partition nor elide any of the data under consensus- your verifiers need to have a copy of everything. Leads to expensive nodes cause disk space and RAM use explodes. Not an uncommon complaint about immutable programming techniques generally. Idk, kinda seems like a bad tradeoff to me. But then again if you're building it on top of the literal money fire that is bitcoin, who cares about scalability and resource use! |
|
Hate to break it to you, but if your consensus rules permit forks, then there's no getting around this. A fork can be mined arbitrarily far in the future that builds off of a block arbitrarily far in the past.
We intend to partition state by application, for applications that are willing to trade smart contract composibility for more block space: https://gist.github.com/jcnelson/c982e52075337ba75e00b799421...
> But then again if you're building it on top of the literal money fire that is bitcoin, who cares about scalability and resource use!
Show me a more resilient blockchain and we'll build on that instead. Popular systems see lots of usage; news at 11.