I suspect that the people who are serious about decentralized trusted computing are neither Bitcoin maximalists nor Ethereum enthusiasts. They’re not Bitcoin maximalists because at the end of the day, they’re interested in using the most tamper-resistant open-membership blockchain (this is currently Bitcoin, but that may change). They didn’t care for Ethereum pre-hard-fork and post-hard-fork because it’s obvious to seasoned distributed systems engineers that Ethereum is poorly designed for this task: by making smart contracts run on-chain, its developers have made it so that the only way to forcibly stop or upgrade a single buggy contract is to hard-fork the whole blockchain.

The best approach is to use the blockchain as a shared “input tape” for off-chain programs. This keeps the blockchain agnostic to the programs that use it (so we shouldn’t ever need to hard-fork it to fix program bugs), and ensures that programs can be individually replaced and upgraded without affecting anyone but their users. It also means that programs can be ported and migrated across blockchains (should better ones be built), and that users who don’t want to upgrade can continue to use older versions with no loss of security. Finally, it makes it so the blockchain only has to scale in the number of applications, not the number of application state-transitions — once application peers can discover one another (i.e. by using the blockchain as the trusted discovery mechanism), they can establish secure off-chain communication channels and storage media and do all their work there.

My colleagues and I have written peer-reviewed computer science articles about this here and here, with supplementary blog posts here and here.