In blockchains, aside from the usual reasons you would store data with error-detection and correction (ordinary data resiliance in storage and transmission), Reed-Solomon is used for:
- Data Availability Proofs, which allows a node to prove it has (or had) access to all the data in a block by transmitting only a tiny subset of that data, which is derived from the RS code and a Merkle hash of the data.
- Execution Proofs, which allows a node to prove the result of an arbitrary and arbitrarily long program executed on data without the recipient having to redo the execution, by transmitting only a tiny subset of the RS code and higher-order codes of the computation's state trace.
Data Availablity Proofs are used with cryptoeconomic incentive structures to ensure that a complete set of data is being stored and periodically checked, and not just the small amount of data that is popular at any given moment. So, like BitTorrent except more reliable because it uses more than just voluntary cooperation; it incentivises keeping whole repositories of data instead of just the popular files within them at any given moment.
Execution Proofs are used with Ethereum-like blockchains to pass around compact summaries of state updates from running code in smart contracts, without all the nodes needing to store or fetch the full state of each contract's memory, or even needing to perform the execution locally to verify it. Smaller Execution Proofs are used in simpler blockchains for the state updates associated with balance transactions.
The data proofs use Reed-Solomon on reasonable sized data blocks, and the trend is towards multidimensional RS, as with other applications.
The second uses Reed-Solomon on much larger vectors than 2^20 points, for long computations, and requires the FFT approach for reasonable performance. However there is still a reasonable upper limit where it makes sense to split the trace up, and for that it's possible to make an Execution Proof of a program which verifies another Execution Proof.