Simple-Coin Integration

[YaronWittenstein]

Simple-Coin Integration

Overview

This document outlines an incremental plan of integrating SVM into go-spacemesh such that in the end, we'll be able to execute Simple-Coin transactions using SVM while having all the required features for Mainnet.

That said, this piece assumes that an Account Nonce is simply an increasing counter. In other words, the Generalized Nonces Schemes is out of scope for this SMIP.

The implications are that implementing other future Templates such as Vault with vesting features won't be possible yet. Writing a future SMIP such as Vesting Vaults Integration might make sense to address the missing parts.

Goals and Motivation

We want to integrate SVM into go-spacemesh to run Simple-Coin transactions through SVM. This document details how to do that on iterations, such that each iteration builds upon its previous one by adding new features.

High-level design

Iteration 1

Outcome

Integrating SVM into go-spacemesh for the 1st time!

What should be implemented?

• Naive Genesis flow - creating a GenesisAccount holding all initial coins upon the system's start.
• go-spacemesh should use go-svm

What would be possible?

• To be able to spawn new Accounts out of existing ones.
• To fund the newly spawned Account as part of the Spawn transaction - this funding amount will be injected into the amount field of the transaction's Envelope.
• To fund an account as part of a Call transaction - this funding amount will be injected into the amount field of the transaction's Envelope.

What won't be possible yet?

• Implementing Signatures Schemes - For now, the verify method will always return true.
• To Self Spawn new Accounts - Instead, Genesis Account will spawn the first few Accounts, and each of them will be able to spawn other accounts as well and so on.
• Use an Immutable Storage - we can defer that implementation since the verify won't use it regardless, as explained above.

Notes

• This iteration is for internal usage (Devnet)
• Since there are no Signatures Schemes used, it means that everyone can send transactions on behalf of any Account (including the GenesisAccount). It's also recommended to work on Process Explorer integration. It'll allow viewing both Transactions and Receipts.

Iteration 2

Outcome

Being able to release a TestNet

What should be implemented?

• SVM Raw Transaction Ranges - implementing this SMIP is a prerequisite for any Signature Scheme implementation.
• VM Transactions Signatures - implementing this SMIP is a prerequisite for any Signature Scheme implementation.
• Single Key Signature - We want the verify method of the SimpleCoin Template to support Single Key verification. The algorithms used should be discussed before the implementation. (as well as the Hash function, Keys length, and anything else related).

What would be possible?

• Implementing multiple Signatures Schemes - Once this iteration is completed. It's recommended to make the SimpleCoin Template work with a MultiSig 2-3 scheme before jumping to the next iteration.

What won't be possible yet?

• To Self Spawn new Accounts
• Use an Immutable Storage - The written code of the Template will make sure that the "Immutable Storage" will be accessed only within the verify function.

Notes

• Once we have two variants of Simple Coin Template (one using a Single Signature and the other MultiSig 2-3 we could run a transaction where the Principal and the Target Accounts each belong to different Templates.
• It's recommended to add some logs as part of the Simple Coin Template - then make sure they are accessible in the Process Explorer. The logs are returned in the Receipts. More info in SVM Receipts Encoding

Iteration 3

Outcome

Supporting Immutable Storage as part of Account Storage.

What should be implemented?

• SVM Immutable Storage

What would be possible?

• Restricting verify to access only Immutable Storage. Enforcing it on the SVM infrastructure level.

What won't be possible yet?

• To Self Spawn new Accounts

Iteration 4

Outcome

Being able to Self Spawn new Accounts

What should be implemented?

• SVM Self-Spawn

What would be possible?

• Self Spawn new accounts - now we can think of a new Template to be implemented leveraging that feature.

What won't be possible yet?

• As mentioned initially, the assumption is that an Account Nonce is an increasing counter throughout the iterations.

Questions/concerns

N/A

Stakeholders and reviewers

@noamnelke @lrettig @neysofu @avive @moshababo

[noamnelke]

That means we need to put any Immutable-like variable into Section 0

And... put any Mutable-like variable into other sections (assuming only section 0 will eventually be immutable).

[avive]

I've got nothing to add besides an observation I'd like to make: once iteration 1 starts more tasks will surface so it is best just to start it even w/o fully committing on the future iterations as they are going to be affected so most important thing is just to agree on outcomes and to move to building asap.

[YaronWittenstein]

I've got nothing to add besides an observation I'd like to make: once iteration 1 starts more tasks will surface so it is best just to start it even w/o fully committing on the future iterations as they are going to be affected so most important thing is just to agree on outcomes and to move to building asap.

[avive]

lol, however these words of wisdom didn't prevent Mike from promoting shitcoins...

[YaronWittenstein]

See the Simple Coin Integration Epics