SVM Raw Transaction Ranges

[YaronWittenstein]

SVM Raw Transaction Ranges

Overview

This SMIP proposes a mechanism for exposing the bytes of the raw transaction while staying compliant with the Fixed-Gas Wasm restrictions.

Goals and Motivation

This SMIP is a prerequisite for applying crypto-related computations on parts of a transaction.
For example, to implement a non-trivial verify function, the Template needs access to the raw transaction data.
Aside from that, other functions should be able to run similar computations.

High-level design

Reconstruct Transaction Raw Data

The way things are designed today is that the Full-Node (go-spacemesh) is in charge of peeling off the Envelope part of a raw transaction (a.k.a, the one sent over the network) decoding it.
The Full-Node must be able to reason about the Envelope, and it can't treat it as an opaque piece of data.

Later, the go-spacemesh (written in Golang) communicates (using the go-svm library) against SVM (written in Rust).
The same Envelope is passed in a binary format between go-svm and SVM due to FFI limitations.

The format used for the Envelope in the FFI boundary isn't the same as the on-the-wire one.
However, since we want SVM to reconstruct the original Envelope, it's advised that the two encodings will converge.
Otherwise, it'll require more coding effort, which seems excessive.

If the Envelope encodings unite into a single one, the interface between go-svm and SVM can remain today.
Right now, the Envelope and Message are passed as two different parameters; it's an implementation detail whether to stay with that explicit separation.

In any case, SVM needs to know how to transform the encoded Envelope passed to it to the one sent over the network.
(If the two Envelope encodings used will be the same, we can view the transformation as the Identity function).

Once SVM will hold both raw pieces, namely Envelope and Message. It could concatenate both and have the original raw transaction.

Host Functions Exposing Raw Transaction Ranges

The Runtime component should be extended with multiple host functions that will expose the bytes range of the raw transaction data.

Each host function will return a tuple representing a memory range.
This list might not be exhaustive, but it should be very close to the final one:

• svm_tx_range() -> (i32, i32)
  Should return a tuple containing the memory range holding the transaction.

• svm_tx_principal_range() -> (i32, i32)
  Should return a tuple containing the memory range holding the transaction's Principal address.
  We probably can omit the tuple second part since we know that an Address is exactly 20 bytes long.
  However, it might be better to stay consistent with the convention used for the other similar methods.
  (and be compatible if additional addresses length will be supported someday).

• svm_tx_calldata_range() -> (i32, i32)
  Should return a tuple containing the memory range holding the calldata.

• svm_tx_verifydata_range() -> (i32, i32)
  Should return a tuple containing the memory range holding the verifydata.

• svm_tx_func_range() -> (i32, i32)
  Should return a tuple containing the memory range holding the function name of the transaction.

Even though Wasm has support for Multiple Return-Values, the Rust support might not be production-ready yet.

In that case, each host function described here will have to be split into two separate functions:
One is returning the starting memory address and the other the ending one. So, for example, instead of having svm_tx_range we'll have both svm_tx_offset and svm_tx_len.

See also the existing svm_calldata_offset and svm_calldata_len as a good reference.

To have the raw transaction in memory, the Runtime will have to copy it into the Wasm instance memory in a very similar manner as done today to the verifydata/calldata.

The call for svm_alloc will take the transaction raw data size into account, and the Function Environment managed by "the host" will keep the ranges of the transaction pieces. It means that the Function Environment will hold pointers to different parts of the raw transaction.

One way to compute these pointers (a.ka offsets) will be by extending the behavior of the Codec not only to return a decoded transaction but also to return metadata containing these offsets.

From there, deriving the memory pointers should be easy.
For example, if we know that the raw transaction starts at memory address 1000 and that the function name field is at offset 50, we can infer that the function name in memory begins at memory address 1000 + 50.

Dependencies and interactions

• go-svm
• SVM FFI
• SVM Runtime
• SVM Codec

Stakeholders and reviewers

@noamnelke
@lrettig
@neysofu
@avive
@moshababo

[noamnelke]

Do you mean to expose actual memory addresses to the contract or am I misunderstanding? Why not make addresses relative to the start of the tx_data and thereby hide the actual memory address? Exposing memory addresses to unsafe code sounds wrong to me.

[YaronWittenstein]

@noamnelke, this SMIP describes host functions for SVM.

For example, we'll require crypto-related functionalities such as SHA3.
Let's say we it'd be called svm_sha3 function - it'd make sense that its signature would expect a memory address pointing to the start of the blob to run the hash function on (and of course, the blob size in bytes as a second parameter)

The svm_sha3 has no idea what's a transaction. It just expects a blob laid out in memory.

[noamnelke]

One way we may be able to work around this issue is to create an opaque Pointer or Range class that's returned from these functions. The wasm code can store instances of this type and pass them along to the hash function, for example, but not use them in unintended ways (e.g. print them in logs or use them for randomness).

[YaronWittenstein]

Wasm was designed from the start to be as deterministic as possible.

As this link describes:

WebAssembly is a portable sandboxed platform with limited, local, nondeterminism.
Limited: nondeterministic execution can only occur in a small number of well-defined cases (described below) and, in those >cases, the implementation may select from a limited set of possible behaviors.
Local: when nondeterministic execution occurs, the effect is local, there is no "spooky action at a distance".

We're supposed to be good since we don't use any of these Wasm features with nondeterminism potential.
Even if we had written Rust code with some randomness (say some Memory Allocator or random numbers) - the resulting Wasm code would have required the assistance of certain host functions targeting the operating system itself.

We don't use any WASI host functions implementations or system-calls polyfills.
It means that the only place we could, in practice, expose nondeterministic behavior is by our written host functions.

My only recommendation is that the SVM code will undergo a security audit.
I don't expect such an audit to find any non-deterministic issues, but it's always good to have another pair of eyes.

And of course, an audit could find other security issues (or maybe things related to potential resources exhaustion such as Stack exhaustion, for example).

@noamnelke @lrettig @neysofu @moshababo @avive

[noamnelke]

I understand what you're saying, but I still feel uneasy about exposing the allocated memory address to contract code.

I understand that it's relative to the sandbox and deterministic, but it still feels like a quirk. What do I mean by quirk? It's an implementation detail of our memory allocator. If we ever decide to change the implementation we must implement backwards compatibility, because past contracts may have done stupid things with the allocated address that affected the results of running the contract code. This makes our memory allocator part of the protocol.

I think we should keep the protocol minimal and there's no benefit in making the memory allocator part of the protocol if we can avoid it. I believe my solution (wrapping memory addresses in an opaque object that can be be interacted with in specific ways) allows us to avoid it. A nice side benefit is that it allows us to migrate to a non-deterministic memory allocator in the future in a backwards compatible way (without affecting contract execution outcomes).

[YaronWittenstein]

A Memory Allocator is essentially a function that looks for free space of a given size in Memory and returns it.

Each contract can use a different Memory Allocation algorithm internally.
Even more - each function in any Wasm contract can implement (in theory) a different Memory Allocation inside.

We use the Rust Memory Allocation interface since we code our contracts in Rust. It's just an implementation detail and nothing related to the consensus.

The EVM bytecode isn't different. It has a couple of opcodes targeting Memory, such as MLOAD, MSTORE, MSTORE8
I don't see any possible bytecode managing without supporting any Memory related opcodes.

[tal-m]

@YaronWittenstein: I have to agree with @noamnelke here. Smart contracts shouldn't need a memory allocator at all -- definitely not for our initial version that doesn't have dynamic memory allocation. When we do add support for dynamic allocation, I agree that we should use opaque handles like Noam suggested. At the WASM level, these can be sequential integers (like file handles in UNIX), so there's no "leakage" of implementation details such as memory allocation strategies.

Regarding the tx data, why not just map it to the beginning of memory (i.e., starting at 0)? This way we don't have to allocate anything, and the user code can easily access it without any special host calls...

Finally, for the hashing API, we should support the standard init/update/finalize interface (e.g., see here ) which lets you incrementally add data to be hashed (rather than having to pass the entire buffer in one step). This makes it much easier to hash more complex messages (or programmatically generated ones) without having to allocate or copy memory.

[YaronWittenstein]

As long as Smart Contracts will use Memory, we'll have support for Memory Allocation. So if we want to have shared data between functions (or Wasm blocks), we need to use Wasm Memory.

Using the Wasm Stack isn't relevant. It can just push and pop out of the top of the Stack. So it's not like rsp register that can point to any random place such as rsp + 100 (and cause security issues).

And even if we could hack the Stack, we shouldn't. The Wasm Stack was meant for expressions computations and not for holding data.

Coming up with a replacement filesystem-like API to create files and get back handles will give, I believe, nothing.
Actually, I think it will make things worst.
It'd result in re-implementing a subset of the Wasm Memory using our own ad-hoc API.

And what'll be the gain? Enforcing the order of allocated file handles numbers?

The current Memory allocation algorithm used (internally) is the most naive I could imagine: just incrementing a counter. There is no leakage of implementation and nothing consensus-related.

Memory allocation doesn't necessarily mean that you need dynamic allocation. Even when you know upfront how much Memory you'll need, you still need to write and read data from it.

You can't decide that the Memory Counter will start at length zero (or another hardcoded offset). Rust tiny minimal runtime will pick another address for you. Further, it's a bad design to assume anything about the initial value of this Counter.

Even if I could enforce the emitted Wasm code to start laying data on Memory offset zero/other constant - I'd never done that since it could easily backfire with a future compiler version. That same design decision holds for any programming language that would compile to Wasm.

The only thing that truly matters is whether the code is deterministic or not. And being deterministic is a must, of course, for any Contract code.

I don't understand how you want to implement an Opaque pointer to Memory. In the end, after peeling off the abstractions layers, you'll end up using the same Wasm Memory opcodes.

I have no problem with having an additional Hash Builder API if required for the 1st Mainnet. Otherwise, I'd wait to the future when it is relevant.

Starting with a simple Hash Once API should suffice, be easier to implement, and be more performant (no need to allocate any Hash-handles internally).

[tal-m]

Let's separate the low-level WASM runtime from the higher-level rust code.

Wasm

The most consensus-critical part is the WASM definition. This is the part that must be part of every node's code, and must be executed identically by all nodes.

Wasm already defines memory the way I would like us to -- a memory is a contiguous, linear array of bytes, with indices always starting at 0. You can only access the memory via explicit load/store opcodes, or via external (host) functions.

All references are opaque, and kept in tables -- so you can ask to call the i'th function in the function table (i.e., the "function handle"), but you can't access any bit representation of the function's address in memory (or its code, of course). Memories are handled in the same way -- there's a table of memory references, and you can load/store by specifying the index of the memory in the table, and the offset into memory (as I understand it, at the moment only a single memory is allowed, but the generic structure is as I described, and the limitation may be lifted in the future).

So there's no need to reimplement wasm memory handling --- it does exactly what we want.

There's already a wasm-friendly way to load constants into memory, by using "data segments" (there are special opcodes to initialize memory with a data segment) --- to make use of this, for example, we could just define the transaction data as a data segment that loads at memory address 0.

Dynamic data structures

For future dynamic data structure support, we can just use Wasm's native reference types, avoiding memory allocation altogether at the wasm level. (e.g., wasm code would get a reference to a key-data storage structure, and host functions for reading and storing data)

Rust

As for the rust part, I guess I don't understand why it needs memory allocation if there's no dynamic memory. If the rust compiler requires dynamic allocation (and thus an allocator) for even the extremely simple contracts we're starting out with, maybe rust isn't the best high-level language for writing the contracts.

[neysofu]

Rust is a good choice precisely for the fact that it gives us near zero-overhead control over the final Wasm code. Our proposed solution to write transaction data to a memory section that is allocated on the fly is orthogonal; that's where the need for a memory allocator comes from, not Rust itself.

NEAR, Substrate and other projects come to mind when talking about Rust usage for smart contracts.

• https://hackmd.io/@nearly-learning/contract-basics-rust#lines-6---7
• https://docs.rs/solana-program/latest/solana_program/entrypoint/index.html

Both NEAR, Solana, and other established projects include a memory allocator by default when writing smart contracts.

@tal-m data segments only solve this problem partially: you still need to choose an unoccupied memory address. Chances are our users are not writing Wasm code by hand, so you're just running the risk of choosing a memory location that the compiler might decide to use for literals, other constants, etc.. Which is obviously very bad. We'd be playing with fire here.

A memory allocator is just a no-brainer. It's a familiar concept that smart contract authors are familiar with: just allocate some memory, write tx data to it with a host call, and there you have it. This pattern is flexible and works for basically everything we need.

This works and it's the most common approach by other projects as well, so I'm inclined to do this.

Circling back to the hashing APIs - I agree that streaming-based hashing APIs are generally preferable. Of course, we don't have a hard requirement for this at the moment so we can go with whatever is the easiest to implement for now. This most likely means simple one-shot hashing, without init / update / finalize.

[tal-m]

A smart contract VM should be treated more like an embedded system than a full-scale computer. It has very constrained resources, some memory is special-purpose and reserved, etc. We definitely don't want to encourage smart contracts to contain big chunks of code just because it's a little easier for our high-level toolchain (from your link above, the "small" allocator is about 1k, which is huge for a contract).

If we have full control over the final wasm code, as you say, we should be able to define symbols at specific locations in memory. There seems to be a way to do this in Rust: https://docs.rust-embedded.org/embedonomicon/memory-layout.html

I think what it boils down to is defining the tx_data as an external symbol, and controlling the linker so this symbol is always set to the correct location in memory.