3 ms·
Don't forget that tweets are not just tweets. In 2016 Twitter handled 3000 images per second (around 20GB per second) [1]. The number undoubtedly increased sinc
by dmitriid 5y ago
Don't forget that tweets are not just tweets. In 2016 Twitter handled 3000 images per second (around 20GB per second) [1]. The number undoubtedly increased since then. There's also video.
Good luck storing those on blockchain :D
[1] http://highscalability.com/blog/2016/4/20/how-twitter-handles-3000-images-per-second.html http://highscalability.com/blog/2016/4/20/how-twitter-handle...
- x-complexity 5y ago> Don't forget that tweets are not just tweets. In 2016 Twitter handled 3000 images per second (around 20GB per second). The number undoubtedly increased since then. There's also video. > Good luck storing those on blockchain :D I'll admit that a normal blockchain would be impossible to store that level of transactional data. Of course that doesn't mean that it isn't possible to store it in a decentralized manner: It does, however, require different methodologies to make it work. Currently, the best attempt at this comes from both Filecoin & Arweave, but they're both coming at the problem at different angles [1]: Filecoin tries to solve the storage problem as a "Pay for X storage for Y time" problem, whereas Arweave is trying to solve it as a "Pay to store X storage forever" problem. Going by Arweave's current stats [2][3], it is possible that the network could be able to handle that level of content generation with a high enough node count. In fact, a stress test of sorts is currently underway, as there's an attempt to try and store the Russia-Ukraine conflict on the network [4]. [1] https://coinmarketcap.com/alexandria/article/the-decentralized-storage-war-filecoin-vs-arweave https://coinmarketcap.com/alexandria/article/the-decentraliz... [2] https://viewblock.io/arweave/blocks https://viewblock.io/arweave/blocks [3] https://viewblock.io/arweave/stat/cumulativeWeaveSizeHistory https://viewblock.io/arweave/stat/cumulativeWeaveSizeHistory [4] https://www.forbes.com/sites/stevenehrlich/2022/02/25/a-blockchain-based-noahs-ark-is-being-used-to-preserve-a-record-of-the-ukraine-conflict/ https://www.forbes.com/sites/stevenehrlich/2022/02/25/a-bloc...
- dmitriid 5y ago> I'll admit that a normal blockchain would be impossible to store that level of transactional data. Of course that doesn't mean that it isn't possible to store it in a decentralized manner Translation: blockchain a) doesn't solve this problem, and b) isn't required for this
- x-complexity 5y ago> > I'll admit that a normal blockchain would be impossible to store that level of transactional data. Of course that doesn't mean that it isn't possible to store it in a decentralized manner > Translation: blockchain a) doesn't solve this problem, and b) isn't required for this Clarification: The data structure of a typical blockchain that is regularly talked about (single-chain, no shard/web) definitely cannot store that level of data. In order to reach that level of data throughput, better data structures are required to do so. Single-chain blockchains are great in terms of determining transaction finality, but are poor in terms of data storage. This doesn't mean that research into decentralized & computationally-assured data storage techniques shouldn't be pursued.
- dmitriid 5y ago> This doesn't mean that research into decentralized & computationally-assured data storage techniques shouldn't be pursued. No, it doesn't, for one simple reason: blockchains is not the only such tech, and "computational assuredness" probably isn't really a requirement for this.
- x-complexity 5y ago> > This doesn't mean that research into decentralized & computationally-assured data storage techniques shouldn't be pursued. > No, it doesn't, for one simple reason: blockchains is not the only such tech Again, reiteration must be applied here: The standard single-shard reference-to-previous-block data structure that is the initial blockchain structure is non-conducive towards decentralized data storage. As stated beforehand: > > The data structure of a typical blockchain that is regularly talked about (single-chain, no shard/web) definitely cannot store that level of data. In order to reach that level of data throughput, better data structures are required to do so. > , and "computational assuredness" probably isn't really a requirement for this. Towards the latter half of your statement, if computational assurance is not required, then standard trust-based storage solutions can be implemented instead. HOWEVER (and it should be stressed with extreme emphasis on the word), in that scenario, concerns about the centralized nature of such a storage solution CANNOT be launched by critics: It was their criticism of decentralized storage solutions that caused the shift towards standard trust-based storage solutions, and thus they cannot criticize the move towards the latter. Otherwise, their criticism is not out of technical concern, but out of personal opinion.