Cautionary Note:
The ideas canvased here reflect a point of view, and end state, that has authoritatively been described as “fundamentally mistaken”
Here the exception probably proves the rule that your instinct is correct. Except when your parachain adopts a consensus protocol that leverages the data model, such as Sui’s Address owned objects. Here you would be implementing your own validation/consensus protocol as an insurance policy for the day the relay chain fails, which current token designs means it is guaranteed to happen, and while it is nigh impossible to predict when, it is possible to predict the triggering event: token designs that don’t have the current token vulnerabilities.
So the constraint on your choices would be: use a data model that can survive the relay chain failure.
Blockchains are definitely in their infancy - no chain has been able to persuade a regulator to sign-off on their various claims (certain misrepresentations – i.e. not just puffery – aside)… but the outlines of an end state are visible and they are trivial, as you have worked out: these are just distributed data stores, or even a network of VM’s with a network shared drive. Both work as a practical mental model.
With that end state visible, you can find that some supporting tech can be reasonably well advanced. Some that come to mind
Relax. Everyone here is struggling, and way out of their comfort zone. Especially the PhD’s - if they weren’t we would already have the SEC publicly blessing DOT.
“The more I learn the more I realize how little I understand.” Source…
That low-level DB tech above is probably mature enough for you to add value?
The only tip I would offer is don’t assume the end state is one blockchain to rule them all
… or even a winner take most end state
Better, in my current view, to work from the premise that there will be a multitude of interchangeable blockchains (relay chains in Substrate parlance, DOTs in Polkadot parlance).