What ways can parachains improve interoperability and increase trust using SPREE?

Question

It appears to me that we find ourselves at a trade off between parachain state transition function (STF) generality vs trustless XCM interoperability. At the current point in time parachains can define how XCM messages will be interpreted and executed. This introduces a requirement of trust between parachains, parachain A must trust that parachain B will execute a message sensibly. To achieve trustless interoperability parachains need some guarantees about how messages will be executed.

I have seen mentions of Shared Protected Runtime Execution Enclaves (SPREE) which appears to be a promising approach that will provide a sandbox with standardised logic for execution of messages. I have seen mention that SPREE would be "opt-in" which leads to a bit of fuzzyness regarding interoperability. Those parachains which do not opt-in could still execute malicious / faulty code meaning that users / parachain devs have to be savvy about which destination parachains they support for XCM.

I'm entertaining the idea of an interoperability-centric relay chain which constrains the generality of the parachain STF such that core pallets such as asset pallets, maybe VM choice, etc are standardised via SPREE. This way parachains require less trust for interop. Could this be achieved and if so how?

I'm guessing there would be a SPREE WASM blob on the relay chain which stores the shared logic and then maybe some validation of parachain STF would be required when registering and upgrading?

Answer 1

NOTE: I am not a SPREE expert, this is just my high level understanding of the space.

The challenge between coordinating any two consensus systems is ensuring that they behave only in ways that the other system expects.

This is especially challenging in the Substrate / Polkadot ecosystem since we have prioritized the flexibility of chains freely upgrading their state transition function, and thus potentially changing those underlying expectations.

SPREE, at a high level, tries to solve this by creating isolated pieces of code (likely independent Wasm blobs), which will maintain their own state and be non-upgradable. Additionally, SPREE could provide proofs of execution or of the final state root to ensure that all expectations are being met between the different blockchains.

This kind of functionality will require an additional set of features and APIs on top of what exists today. For example, being able to interface between the runtime and SPREE modules, having separate state trees for the SPREE modules, and even a set of XCM APIs specific for cross-chain SPREE interactions.

While you can make constraints like the ones mentioned above, and try to maintain an ecosystem of chains which only use a specific set of pallets, it does not seem like the tools are available which will be able to enforce that logic. In which case, you are not actually better off than today where different parachains simply need to coordinate to ensure that the end to end scenarios of those chains are working.

While this situation is not ideal in the long term, it seems perfectly reasonable for now, especially given the fact that we do have a long term plan. As with any bleeding edge software development, you cannot simply wait to release code until everything is "perfect". The current state of parachain coordination is a reasonable milestone on our way to truly trustless multi-chain systems. Given the large parachains deposits and limit slots available, chains are socially and economically incentivized to behave well. Even if they don't, Polkadot governance can jump in an make things right again.

So in summary, SPREE will certainly solve some of the issues with parachain coordination and trust that currently exists today on Polkadot, but there is quite a bit of work needed to make SPREE a reality. As with any backlog, we need to prioritize items based on needs, and scaling the performance of parachains is the key focus at this time, since coordination is a problem that can be solved off-chain.