[neathack]

Let's assume just for a second that copyright violation isn't a problem, that 1B is enough to motivate enough people, that it's not overrun by bots, etc..

What kind of blockchain would actually be able to deal with the expected transaction count? According to [1] Ethereum peaks out at 15 transactions per second, but [2] claims around 6.000 tweets per second on average.

A difference of 2–3 orders of magnitude is not something a team of 5 engineers can simply solve in 6 months.

[1]: https://blog.coinbase.com/scaling-ethereum-crypto-for-a-bill...

[2]: https://www.internetlivestats.com/twitter-statistics/

[dmitriid]

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-handle...

[x-complexity]

> 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-decentraliz... [2] https://viewblock.io/arweave/blocks [3] https://viewblock.io/arweave/stat/cumulativeWeaveSizeHistory [4] https://www.forbes.com/sites/stevenehrlich/2022/02/25/a-bloc...

[dmitriid]

> 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]

> > 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]

> 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]

> > 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.

[x-complexity]

> What kind of blockchain would actually be able to deal with the expected transaction count? According to [1] Ethereum peaks out at 15 transactions per second, but [2] claims around 6.000 tweets per second on average.

Admittedly, the only way to be able to achieve that level of throughput would be to require zk proofs for assured transaction finality, on top of being a Layer 2 scaling solution.

Currently, that level of throughput can be obtained by using a specialized ZK-rollup network like StarkNet [3] if it needs to be deployed right now. Otherwise, zkSync 2.0 [4], an EVM-compatible general ZK-rollup, is currently in its testnet stages & is currently the desired goal for scaling Ethereum's TPS up to the desired amount.

The technology is currently still in it early stages, as demonstrated by zkSync & StarkNet, the capability to reach that level of throughput is possible.

[3] https://starkware.co/starknet/ [4] https://v2-docs.zksync.io/dev/