Maybe, to some extent. But keep in mind that computation would still need to be deterministic. So it would still likely imply Wasm code compiled against the IC’s system API, rather than arbitrary code. Or you could easily run the risk of running some computation for hours on end across all replicas on a subnet only to find out that they disagree (which I understand is a common issue with e.g. HTTP outcalls).
So IMHO this is definitely not a silver bullet.
Furthermore, this is a half-baked idea that we’ve been poking at every now and then. As said, I for one have no clue how one would decide what to include into a block, so you don’t end up with 2f+1 replicas making progress and f replicas constantly state syncing; only to then stall the entire subnet as soon as one of the 2f+1 replicas has any kind of issue.
So until we figure that one out, ensuring that it degrades gracefully (i.e. throughput is reduced progressively depending on the number of replicas at consensus height rather than everything working fine up to a point and then stalling for half an hour), it’s only an idea.
And once we’ve got everything figured out, we’d need to put a number of things in order (as said, persistence layer, messaging, overhead) and then spend probably up to a year putting together the pieces of the puzzle.
But sure, feel free to kick off the discussion.