SVM Self-Spawn

Overview

This SMIP details the Self Spawn functionality from SVM's perspective, along with the required changes for its implementation.

Goals and Motivation

We want to spawn new accounts in the Self Spawn manner. In that case, a newly spawned account will have an initial balance pending him for usage. Spawned accounts will also use it for paying for their spawning. This feature will ease the onboarding of new real-users on the Spacemesh platform.

High-level design

Create Stub Account

In the beginning, an existing account is executing a transaction. While the transaction is running, the current account calls transfer to a non-existing account at some point.

The side-effects of this call will be creating a new account detached from any Template. We'll call such an account a Stub Account or Inactive Account. It will have an initial balance (the amount transferred upon creation), but it won't be eligible for running transactions.

The reason for that is obvious - since there is no Template associated with it. Also, note that transferring coins to a Stub Account should be completely valid.

The Global State component should upgrade to support Stub Accounts. One option is to make the Template an optional attribute and keep things as today. We can also add an explicit mode attribute. It'll serve as a flag for active/inactive.

The Runtime will have to be aware of the possibility of a Stub Account. Therefore, before running a Call transaction, it will have to assert that the target account is active.

Activate Account (a.k.a Self-Spawn)

The way to turn a Stub Account into being active is by executing a Self Spawn transaction. This Self Spawn differs from the currently existing Spawn one by the source of the Principal account. On the current Spawn, the Principal address is associated with an existing account - and it'll pay for the Gas cost of the transaction.

In the Self Spawn case, the Principal address is the address of an inactive account - the one to be spawned. This requirement implies that we should compute the Self Spawned's address ahead of time deterministically.

The formula used should be known and deterministic. It should be independent of the layer that will run the Self Spawn transaction. It's critical since we can't guarantee what layer the Self Spawn will execute.

The steps for executing a Self Spawn are as follows:

Extract the Principal field. If its value is associated with an active account, proceed with the default Spawn flow today. If there is no account related to that address - the transaction fails. Else, we have a Principal attached to an inactive account - we need to proceed with the Self Spawn flow.
Associate the Template of the inactive account to the Template field provided by the transaction. That is a symbolic change. Actual changes should be committed to the Global State only upon a successful transaction.
Initialize the initial Immutable Storage of the inactive account with the data given by the transaction. As explained at the Immutable Storage SMIP - this data should be committed only upon the transaction's success.
Set the execution mode of the inactive account to Read-only Immutable Even though we deal with Fixed-Gas Wasm programs, we can't determine everything by doing static analysis. Static analysis can ensure we're not writing to storage within a given function. But not necessarily whether we're attempting to read an immutable variable or not. For that reason, we need to support that restricted mode explicitly. So, for example, if a function running under Read-only Immutable will try to read a mutable variable, the Runtime should halt the transaction and fail.
Execute the verify / constructor function (see the SVM Transaction Life-cycle SMIP).
After executing the constructor function successfully, we can officially turn the Stub Account active. The Template associated with it will be pinned, and the Immutable Storage will be committed as well.
The Gas payment for the Self Spawn transaction will be withdrawn from its balance.
Since we're dealing with Fixed-Gas Wasm, we can infer how much Gas will be required to run both the verify and constructor without running any code. In case of the inactive account lacks balance, we should fail the Self Spawn transaction.

Questions/concerns

Do we want to keep the current Spawn functionality, or will the Self Spawn suffice for our needs?

Dependencies and interactions

Before implementing this SMIP, it's suggested first to implement the Immutable Storage functionality.
In practice, the verify function will require dealing with signatures and having access to the raw transaction bytes. There will be a separate SMIP addressing the required features. However, most Self Spawn SMIP can be implemented without the signatures functionality.

Stakeholders and reviewers

@noamnelke @lrettig @neysofu @avive @moshababo

spacemeshos / SMIPS

SVM Self-Spawn #64