-
Notifications
You must be signed in to change notification settings - Fork 1
AA Transactions & SVM Integration #53
Comments
I think it is important to add some design regarding signatures to the smip that answers these questions:
|
@avive There's no specification for what is signed at this level. The signatures are decoded and verified in the I think there should be a separate SMIP (maybe SMIPs) for the specific account types we'll have at launch. Each account type specifies the answers to your questions (Except for q.4, which is common for all of them --- because raw signature verification must be supported in native code on the SVM side --- and possibly q.5 --- see below). Q.5 actually is a bit tricky, and does relate to this SMIP. We have to keep in mind that sometimes decoding of the envelope is actually transaction-dependent. This is the case, for example, when we're doing public-key extraction. The encoded transaction in this case doesn't have the principal's address. Instead, the address is extracted from the signature. We said we'd solve this by having an external "decoding" layer, that recognizes specific transaction types and "decodes" the principal address by running the PK extraction. If this decoding is done on the go side, as you suggest in this SMIP, there will be some duplication of code --- both the decoder (in go) and the Alternatively, we can have the transaction decoding step also take place on the SVM side, which I think is a little cleaner in terms of software design. This would potentially allow us to encode/decode in more optimized ways in the future, and my guess is that it would be more efficient as well (since there's less context switching between go and SVM). |
Is this "version" of the transaction object or SVM version? If the latter, maybe we could give this a more generic name such as "vm_type" (since it may not just be a version, it may indeed include both the name of the engine -- svm, evm, rollup-specific engine, whatever -- and the version)
paying for the gas and the source of funds for
gas limit and gas fee semantics here depend upon whether we go with an EIP-1559-like mechanism, which seems likely.
might want to explain how the identifier is calculated. in EVM it's a hash of the full function signature - I assume we want to do something similar? |
Versioning of the Transaction Object.
OK. I'm certain that the
I'll read this EIP.
I don't think we need to use any hashing because in Wasm there is no function overloading, the function name is a unique identifier. Also, the compiled Wasm (SVM SDK -> Wasm) will contain very short names for these functions in order to reduce the space of a transaction. |
If all the Envelope fields are final then next step in this smipp should be providing the data type of each Envelope member and the Envelope binary codec. This will move us towards clients being able to create sm 0.3 transactions (and decode them for display to users) and explorers decoding them for display purposes. |
Additional things that should be added to this smipp (or to a followup one) that we need in order implement 0.3 transactions:
I understand that specing the fields for vault smart contract transaction (spawn and call) is not possible yet until the vault contract is designed but we should be able to spec these fields for a simple coin transaction. |
Overview
This SMIP will outline the required changes to the platform Transactions as a result of shifting towards the new
Account Unification
(#49) model and SVM Integration.Additionally, the upcoming integration of
go-spacemesh
withSVM
will require significant changes for clients as well.Existing clients such as
smapp
andProcess Explorer
will have to adapt accordingly.Goals and motivation
The motivation for this SMIP is to streamline the integration process between
go-spacemesh
andSVM
. Getting everyone up to speed with the same terminology and agreeing on the way things will workis crucial.
In the new
Account Unification
(#49) model each Transaction will essentially be a Smart-Contract transaction,or
SVM transaction
if to be more precise. Even simple coins transactions will be implemented as a Smart-Contract.In
SVM
there is a distinction between deploying a Smart-Contract spec and creating instances of it.A Smart-Contract specification is named a
Template
and each live instance is called anAccount
.Each
Account
will have anAddress
and abalance
andTemplate Address
it was spawned from.It will contain more internals which are out of scope for this document.
There are in total 3 types of Transactions SVM v0.3:
Deploy
- DeployingTemplates
.Spawn
- SpawningAccount
s out of deployedTemplates
.Call
- Calling an existingAccount
.This SMIP will detail the fields that each Transaction will consist of without getting into low-level encoding.
High-level design
Each binary (over-the-wire)
Transaction
will consist of two main parts:Envelope
- ATransaction
agnostic content.Message
- ATransaction
specific content.Each
Message
will be accompanied by theEnvelope
to form together a complete binaryTransaction
.In addition to the explicit data sent over-the-wire, there will be implicit fields inferred from it.
One such example is the
Transaction Id
. For the context of this document, we won't regard these implied fields as part of theTransaction
.Adding to a binary
Transaction
, there is theExecution Context
(or alternatively theTransaction Context
or simplyContext
). TheContext
structure will contain additional data (alongside theTransaction
) to be used by SVM when executing aTransaction
. Properties such asLayer
orBlock Number
and theState Root Hash
will be part of it.It'll be probably useful to attach implied properties such as
Transaction Id
as well to sit under theContext
.When SVM will be given a
Transaction
to execute it'll receive both theTransaction
data and its attachedContext
.Proposed implementation
Since
SVM
is implemented in Rust andgo-spacemesh
in Golang, it's of key importance to make life easier as muchas possible when designing the integration.
In order to make the two components talk, they will have to abide the FFI rules.
Each successful
SVM
CI will emit os-specific (macOS/Linux/Windows
) binaries.SVM FFI layer will be wrapped by a project named
go-svm
, serving as the bridge between Golang and Rust.Any
cGo
related code will be handled by it. It will expose pure Golang API and mask any FFI related code to the external world.The
go-spacemesh
will depend ongo-svm
and know nothing about its internals.Generally, each call to
go-svm
for the sake of validation or execution will be equipped with:1. Envelope
The parsed
Envelope
as a Golang struct.Peeling off the binary
Envelope
out of a binaryTransaction
is the responsibility of thego-spacemesh
.2. Message
The binary
Message
is what's left after peeling-off theEnvelope
out of a binaryTransaction
.This data is opaque to
go-spacemesh
and it will be passed as it's forward to thego-svm
.3. Context
The
Context
will be passed as a Golang struct intogo-svm
.It will contain inferred data from the binary Transaction (e.g
Transaction Id
) and execution related data (e.glayer
/State Root Hash
).Transactions Fields
Envelope
version
- For versioning (to ease introducing new changes in the future).type
- TheTransaction
type (Deploy / Spawn / Call
)principal
- TheAddress
of theAccount
paying for the Gas.amount
- For funding.tx_nonce
- For the tx nonce.gas_limit
- Maximum units of Gas to be paid.gas_fee
- Fee per Unit of Gas.The exact Encoding of the
Envelope
will be decided by thego-spacemesh
team.It can be
XDR
or any other encoding. Thego-svm
expects to receive an already parsedEnvelope
sin the form of a Golang struct.
Message
Deploy
The
Deploy Message
will be generated by theTemplate
compiler.Right now it'll be using the
SVM SDK
, but in the future there might be more ways to achieve that.Spawn
Each
Spawn Message
contain the following fields:template (Template Address)
- TheTemplate
we'll spawn anAccount
from.name (String)
- Thename
of theAccount
(optional).ctor (String)
- Theconstructor
identifier to execute.calldata (Blob)
- The input for theconstructor
to run.Call
target (Account Address)
- TheAddress
of theAccount
which we're calling.function (String)
- The function`s identifier to execute.verifydata (Blob)
- The input forverify
. See theAccount Unification
for more details.calldata (Blob)
- The input for the thefunction
to run.The Encoding of each
Call Message
will be implemented bySVM
which will provide asvm_codec.wasm
.Each successful
SVM
CI build will emit under its Artifacts thesvm_codec.wasm
.Dependencies and interactions
SVM
- TheTransaction
executor.go-svm
- The glue betweengo-spacemesh
to SVM binaries.go-spacemesh
- Communicates directly only againstgo-svm
.Stakeholders and reviewers
@YaronWittenstein
@neysofu
@noamnelke
@sudachen
@lrettig
@avive
The text was updated successfully, but these errors were encountered: