Hey @shawntabrizi, sure. I would like to stress that I am not advocating a complete departure from the term “parachains”. The term can still be used in relevant docs specific to parachains, i.e., where a rollup is a parachain (currently the only case on Polkadot).
In the Academy material, I would state that a parachain is a rollup (chain) and then explain how the Polkadot rollup system differs from others.
I would do the same in the Substrate Docs. We could keep parachains as a main terminology OR say that “we use the term rollup chain from now on to refer to parachians” (IMO this would be best).
In the Wiki, I would suggest to
- explain how parachains are basically rollup chains
- compare Polkadot rollup with others on a dedicated page
- remove the term parachain and replace it with rollup or rollup chain on most pages
- leave parachains in some specific guides
Regarding your examples, I think they all make sense, and we could add some more context to it:
- We use Polkadot’s rollup technology to secure Web3 applications and services.
- Polkadot’s mission is to provide a secure, scalable, and resilient platform for Web3 applications and services.
- You can build a Web3 application on Polkadot using the Polkadot SDK. To benefit from Polkadot’s interoperability and security, you can plug your rollup into a Polkadot core by purchasing coretime.
We must put ourselves into business people wanting to deploy their solutions on a web3 infrastructure. In my experience, those people always want a comparison table between different existing solutions. The problem with utilizing “parachains” is that it raises questions like “Why is Polkadot not using rollups?”, “What is the difference between a parachain and a rollup?”, etc.
Now, given all Gav speeches about JAM, saying that JAM is a rollup reactor, that Polkadot essentially is a rollup chain, we need to embrace the fact that Polkadot is a rollup chain, that Polkadot has rollups, and that these rollups are similar to Ethereum rollups BUT with some (significant) differences that can benefit enterprises (scalability, security because Polkadot rollup tech always checks stuff, etc.). I would not use the term cynical because cynical is a negative term, and I would instead deploy an optimistic rollup rather than a cynical one.
My suggestion is to “play simple” and just use Polkadot rollups when generally speaking, rollup chain when talking about existing L1s deployed in Polkadot, and just rollups when there are multiple repetitions in the same page / doc. When there is the need to go into more detail, we can explain how their rollups are being secured.