AA Transactions & SVM Integration #53
This SMIP will outline the required changes to the platform Transactions as a result of shifting towards the new
Additionally, the upcoming integration of
Goals and motivation
The motivation for this SMIP is to streamline the integration process between
In the new
There are in total 3 types of Transactions SVM v0.3:
This SMIP will detail the fields that each Transaction will consist of without getting into low-level encoding.
Each binary (over-the-wire)
In addition to the explicit data sent over-the-wire, there will be implicit fields inferred from it.
Adding to a binary
When SVM will be given a
In order to make the two components talk, they will have to abide the FFI rules.
SVM FFI layer will be wrapped by a project named
Generally, each call to
Peeling off the binary
The exact Encoding of the
The Encoding of each
Dependencies and interactions
Stakeholders and reviewers
The text was updated successfully, but these errors were encountered:
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.