> 1. Scalability issues related to a very large block chain size and the associated difficulty in bringing up and running a full node. This is a problem of 2 p

> 1. Scalability issues related to a very large block chain size and the associated difficulty in bringing up and running a full node. This is a problem of 2 parts: Transaction scalability & Storage scalability. Transaction scalability's currently being resolved with various optimistic & zk-based rollup solutions, with the latter rolling out next year (zkSync 2.0, Scroll, & Polygon Zero & Miden) and the former already being improved upon & decentralized (Optimism & Arbitrum). There are still guardrails in place, as they're still being developed/improved on. https://l2beat.com/scaling/risk https://l2beat.com/scaling/risk Storage scalability's a different issue that's also being worked on via data availability (DA) sampling, whereby the use of erasure codes & random sampling allows for data to be split into chunks & distributed amongst the network. With this system, every node doesn't need to hold onto all of the data: The whole network only needs to provide at least 51-99% (depending on the erasure code used) of the chunks to reconstruct the block, verify, & republish the block for everyone else. By doing so, the average case for a node is reduced from "store all data" to "store 1/n of all data", with N being the number of data shards for the entire network. Another way that's being worked on is the creation of Validium rollups, wherein the data is stored off-chain but it can still be proven via proofs published on-chain. It's not as secure as a fully on-chain rollup, but in return, the rollup consumes significantly less gas. https://twitter.com/VitalikButerin/status/1588669782471368704 https://twitter.com/VitalikButerin/status/158866978247136870... https://pbs.twimg.com/media/FgwVhUjaAAEx_Bb?format=jpg&name=large https://pbs.twimg.com/media/FgwVhUjaAAEx_Bb?format=jpg&name=...