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?

  • Hey Tau, welcome to the community! i wanted to ask, might you edit this question to be more succinct and identify what the overall question is? It's hard to parse as is, without sections / headers / line breaks. substrate.stackexchange.com/help/how-to-ask is worth a look too to get started
    – Nuke
    Apr 29, 2022 at 17:32
  • Let me see if I understand: you want to use a SPREE to form a kind of mediator/enforcer of continued interoperability between parachains (as needed, with a restricted generality of things like runtime upgrades)?
    – Nuke
    Apr 29, 2022 at 18:14
  • From my limited understanding of SPREE, it was more generally to be used as the name implies: mediate state transitions off of a parachain that it cannot directly change with runtime upgrades and (for anything but perhaps a relay chain governance common good parachain) could not force state on. Breaking interoperability for general XCM that isn't mediated by SPREE didn't fit my mental model of what it could do, until now.
    – Nuke
    Apr 29, 2022 at 18:14
  • so seeing these two models: SPREE acting only as a 3rd party state machine vs. SPREE acting as a limited authority on general execution on other chains.
    – Nuke
    Apr 29, 2022 at 18:14

1 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.

  • Thanks for taking the time to provide such a comprehensive and insightful response! I've got a lot to say in response to but the comment field is limited to ~500 characters. Is there a research platform / forum where we can discuss in a more interactive manner as opposed to the Q/A + comments style?
    – TauLepton
    Apr 30, 2022 at 13:52
  • 1
    Probably best to open an issue somewhere like here: github.com/w3f/polkadot-spec/issues
    – Shawn Tabrizi
    Apr 30, 2022 at 13:56
  • thank you I'll be sure to do that
    – TauLepton
    Apr 30, 2022 at 14:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.