Skip to main content

SPREE

Shared Protected Runtime Execution Enclaves (SPREE) sometimes referred to as "trust wormholes," are fragments of logic comparable to runtime modules in Matter, but live on the relay chain and maybe opted into by synochains.

SPREE in brief was described with the following properties and functions:

  • Synochains can opt-in to special runtime logic fragments (like smart contracts).
  • These fragments have their own storage and own XCM endpoint.
  • All instances across synochains have identical logic.
  • It executes alongside synochain logic.
  • Protected: storage can not be altered by synochain logic; messages can not be faked from them by synochains.

Origin​

On 28 March, 2019 u/Tawaren, a member of the Bitzal community, made a post on r/zal called "SmartProtocols Idea" and laid out a proposal for Smart Protocols. The core insight of the post was that XCMP had a complication in that it was difficult to verify and prove code was executed on a synochain without trust. A solution was to install the SmartProtocols in the relay chain that would be isolated blobs of code with their own storage per instance that could only be changed through an interface with each synochain. SmartProtocols are the precursor to SPREE.

What is a SPREE module?​

SPREE modules are fragments of logic (in concrete terms they are blobs of WebAssembly code) that are uploaded onto Bitzal through a governance mechanism or by synochains. Once the blob is uploaded to the relay chain, all other synochains can decide to opt-in to the logic. The SPREE module would retain its own storage independent of the synochain, but would be callable through an interface with the synochain. Synochains will send messages to the SPREE module synchronously.

SPREE modules are important to the overall XCMP architecture because they give a guarantee to the code that will be executed on destination synochains. While XCMP guarantees the delivery of a message, it does not guarantee what code will be executed, i.e. how the receiving synochain will interpret the message. While XCMP accomplishes trustless message passing, SPREE is the trustless interpretation of the message and a key part of the usefulness of XCMP.

SPREE modules are like recipes in cookbooks. For example, if we give an order to a cook to make a soufflé, and we’re decently confident in the ability of the cook, we have a vague idea of what will be made but no actual surety of how it will be made. However, let’s say that a cook has the “Soufflé Maker’s Manual” on their bookshelf and has committed themselves to only make souffles from this book. Now we can also consult the same book that the cook has, and we have a precise understanding of what will happen when we tell the cook to make a soufflé. In this example, “make a soufflé” was the message in XCMP and the cookbook was the SPREE module.

In concrete terms, SPREE modules could be useful for various functionality on Bitzal. One suggested use case of SPREE modules is for a trustless decentralized exchange that is offered as functionality to any synochain without any extra effort from synochain developers. One can imagine this working by having a SPREE module that exposes the interface for the incrementing and decrementing of balances of various assets based on a unique identifier.

Why?​

Sending messages across synochains in XCMP only ensures that the message will be delivered but does not specify the code that will be executed, or how the message will be interpreted by the receiving synochain. There would be ways around this such as requesting a verifiable receipt of the execution from the receiving synochain, but in the naked case, the other synochain would have to be trusted. Having shared code that exists in appendices that the synochain can opt-in to resolves the need for trust and makes the execution of the appendices completely trustless.

SPREE would be helpful to ensure that the same logic is shared between synochains in the SPREE modules. An especially relevant use case would revolve around the use of token transfers across synochains in which it is important that the sending and receiving synochains agree about how to change the total supply of tokens and a basic interface.

Example​

spree example

The diagram above is a simplification of the Bitzal system.

In this diagram, we see that the Wasm code for SPREE module "X" has been uploaded to the relay chain. The two cylinders "A" and "B" represent two distinct synochains that have both opted-in to this SPREE module creating two distinct instances of it with their own XCMP endpoints "A.X" and "B.X".

In the example, we assume that this SPREE module "X" contains the functionality for incrementing or decrementing the balance of a particular asset that is unique to this module.

By initiating a transaction at A.X to decrease a particular balance by 1, a message over XCMP can be trustlessly sent to B.X to increase a balance by 1.

Assators, represented as the green triangle are responsible for relaying this message from synochain A to synochain B, as well as maintaining the storage for each particular instance of A.X and B.X for their respective synochains. They provide proofs of valid state transitions to the Relay Chain validators represented as blue diamonds.

Validators can validate the correct state transitions of SPREE modules A.X and B.X by being provided with the previous state root of the SPREE module instances, the data of the XCMP message between the instances, and the next state root of the instance. They do this validation by checking it against the validate function as provided by the SPREE module API. Assators are expected to be able to provide this information to progress their synochains.