Overview / Motivation

We'd like to auto-generate the svm_wasmer.h file for the svm-runtime-c-api

The Task

We'd like to auto-generate a svm_wasmer.h C-header file out of this Rust file: https://github.com/spacemeshos/svm/blob/develop/crates/svm-runtime-c-api/src/c_api.rs

Implementation Notes

1. Currently, the svm_wasmer.h C-header file is manually built: https://github.com/spacemeshos/svm/blob/master/crates/svm-runtime-c-api/examples/svm_wasmer.h

2. Please use this link as a reference: https://doc.rust-lang.org/cargo/reference/build-scripts.html

3. Please use cbindgen for the task.

You may want to take a look at this code of wasmer as a good reference for using cbindgen https://github.com/wasmerio/wasmer/blob/master/lib/runtime-c-api/build.rs

4. The svm_wasmer.h file should be auto-generated as part of cargo nightly build (SVM requires Rust nightly)

5. If possible, please auto-copy the generated svm_wasmer.h C-header file also to: https://github.com/spacemeshos/svm/blob/develop/crates/svm-runtime-c-api/examples/

Contribution Guidelines

Important: Issue assignment to developers will be by the order of their application and proficiency level according to the tasks complexity. We will not assign tasks to developers who haven't introduced themselves on our Gitter dev channel

1. Introduce yourself on svm dev chat channel - ask our team any question you may have about this task
2. Fork branch develop to your own repo and work in your repo
3. The code must be formatted using rust fmt
4. You must write unit tests for all types and methods when submitting a component.
5. When ready for code review, submit a PR from your repo back to branch develop
6. Attach relevant issue to PR

Overview / Motivation

Currently, we have a very basic build using Travis CI.

We'd like to create a build-pipeline for Mac and Linux. SVM won't compile on Windows yet, but the preparation work can be done already.

The Task

We want to have the following build pipelines:

• Linux Desired output: (both debug and release)
  • libsvm_runtime_c_api.so
  • svm_wasmer.h
  • wasmer
    • libwasmer_runtime_c_api.so
    • wasmer.h
• Mac Desired output: (both debug and release)
  • libsvm_runtime_c_api.dylib
  • svm_wasmer.h
  • wasmer
    • libwasmer_runtime_c_api.dylib
    • wasmer.h
• Windows (preparation since SVM doesn't work yet on Windows) Desired output: (both debug and release)
  • libsvm_runtime_c_api.dll
  • svm_wasmer.h
  • wasmer
    • libwasmer_runtime_c_api.dll
    • wasmer.h

Implementation Notes

1. Please implement the CI using Travis CI. If you'd like to use GitHub Actions we might go for it.
2. Please create separate branches for Mac / Linux / Windows.
3. • SVM require rust nightly, please build using this command: cargo +nightly build
4. Tests shouldn't run in parallel (we'll explain why on the Gitter chat). Please run the tests using this command: RUST_TEST_THREADS=1 cargo +nightly test --all --release
5. In case not all tests pass, the build must fail abruptly

Contribution Guidelines

Important: Issue assignment to developers will be by the order of their application and proficiency level according to the tasks complexity. We will not assign tasks to developers who haven't introduced themselves on our Gitter dev channel

1. Introduce yourself on svm dev chat channel - ask our team any question you may have about this task
2. Fork branch develop to your own repo and work in your repo
3. The code must be formatted using rust fmt
4. You must write unit tests for all types and methods when submitting a component.
5. When ready for code review, submit a PR from your repo back to branch develop
6. Attach relevant issue to PR

Overview / Motivation

Trying to build svm project on local ubuntu 22.04

The Task

1. Rust nightly setup done from following link - https://doc.rust-lang.org/1.2.0/book/nightly-rust.html

2. Cloned [svm] - git clone https://github.com/spacemeshos/svm.git

3. Executed build command - cargo build

4. Error Output for cargo build -

error: couldn't read crates/host/genesis-config/src/../../../../simple-coin-transfer-template/simple_coin_transfer_template.wasm: No such file or directory (os error 2)

--> crates/host/genesis-config/src/lib.rs:40:9 | 40 | / include_bytes!( 41 | | "../../../../simple-coin-transfer-template/simple_coin_transfer_template.wasm" 42 | | ) | |_________^ | = note: this error originates in the macro include_bytes

5. Seeking guidance to build the svm repo successfully

Implementation Notes

Followed the project's readme

Overview / Motivation

We want to simulate a failed exec app transaction. The returned receipt should indicate that the transaction failed along with an error message.

The Task

The task will require decoding a raw receipt of a failed transaction and printing the failure reason.

Implementation Notes

1. The raw format of a receipt of a failed transaction can be found here: https://github.com/spacemeshos/svm/blob/develop/crates/svm-runtime-c-api/src/receipt.rs#L15
2. Add a file named panic.wasm under examples/c/wasm

Contribution Guidelines

Important: Issue assignment to developers will be by the order of their application and proficiency level according to the tasks complexity. We will not assign tasks to developers who haven't introduced themselves on our Gitter dev channel

1. Introduce yourself on svm dev chat channel - ask our team any question you may have about this task
2. Fork branch develop to your own repo and work in your repo
3. The code must be formatted using rustfmt
4. You must write unit tests for all types and methods when submitting a component.
5. When ready for code review, submit a PR from your repo back to branch develop
6. Attach relevant issue to PR

This is a follow-up PR to https://github.com/spacemeshos/svm/pull/411.

https://github.com/spacemeshos/svm/pull/390 fixed a Fixed-Gas regression in svm-abi-decoder, meaning that some code had been merged into master which caused the compiled .wasm artifacts to contain illegal loop instructions. This broke SVM Fixed-Gas mode, so we reverted back to using pointers within Cursor.

This PR mitigates the two issues:

• It doesn't compile into any loop instructions and invalid WASM code.
• It reverts some of the safety improvements applied before breaking Fixed-Gas. In particular, we introduce back explicit lifetimes, which help the compiler check for some useful invariants and reduces the UB surface.

One of the requirements raised as part of the integration with go-spacemesh is that an Account should get a reward. This is a printing coins like functionality doesn't involve any sender party.

The task is to implement an increase_balance functionality for the Global State and have it exposed in the FFI layer (to be consumed by go-svm)

Notes

Before working on this issue, please make sure this one is addressed #406

Details

While calling an existing Account (i.e., executing a Call transaction) and spawning new ones (involves running a constructor), we might transfer coins between different Accounts.

go-spacemesh would like to be notified which accounts were involved in coins transfers as part of executing a transaction.

In other words, each time the svm_transfer host function is being called, we'd like to append the source and destination into the Touched Accounts set.

The logged source will always be the same Address - the currently executing Account. So the implementation can optimize that, but keeping things simple and stupid in the solution might be a better approach.

The task of the issue is to make sure that Spawn and Call receipts will have a new touched_accounts field that will contain this list of Account Addresses.

Encoding

Lastly, this field should also be encoded in the returned Receipts.

See the svm-codec code here: https://github.com/spacemeshos/svm/tree/master/crates/codec/src/receipt

@sudachen has pointed out that the current SVM Windows Artifact is corrupted and he suggested two ways to tackle it:

• Use dlltool @sudachen - can you please elaborate what commands need to be used here?

• Use the x86_64-pc-windows-gnu toolchain explicitly when compiling to Windows. @sudachen - is anything missing here?

@neysofu @moshababo @noamnelke FYI

Motivation

An Address and PublicKey take 20 and 32 bytes respectively. Supporting these two primitives efficiently (and elegantly) is essential.

Also, the fact that Wasm Memory lays-out in Little-Endian order should not matter. 

The mechanism for feeding an app's method with raw data is using the function buffer (func_buf for short). SVM copies the func_buf data in the Wasm Instance Memory (i.e App's Memory).

From that point, an application may want to store part of the func_buf for long-term use (i.e Applications' storage).

Using the existing get160 and set160 will result in messing the raw data. Here is an explanation. We start from having 20 bytes in Memory (the data copied from func_buf).

1) Address (20 bytes) = A1A2A3A4A5A6A7A8    B1B2B3B4B5B6B7B8    C1C2C3C4

2) Loading from Memory the Address into 3 integers using will result in:
(using wasm Memory load opcodes)

a = A8A7A6A5A4A3A2A1
b = B8B7B6B5B4B3B2B1
c = C4C3C2C1

3) Storing these integers using `set160(var_id, a, b, c)` will give us:

A8A7A6A5A4A3A2A1 B8B7B6B5B4B3B2B1 C4C3C2C1

Now the 20 bytes are laid out in a different order than the original one

4) Now, reading from the storage `get160 -> (a: i64, b: i64, c: i64)`

a = A8A7A6A5A4A3A2A1
b = B8B7B6B5B4B3B2B1
c = C4C3C2C1

Instead of the above - by using the this PR new store160 will do a plain copy of memory raw data into storage. The data stored will be the same as the original one.

Having the existing get160/set160 has there place too. They are great when we'd like to compare Address-es faster by doing integer comparisons (Instead of looping-over memory and having many compares).

That's why I think there is room for both get160/set160 and load160/store160. (The same applies for 256-bit of course).

This PR addresses issue#406, i.e. introducing a new host function that sends coins from the current executing account to a destination account.

TODO:

• Investigate why loading the source account succeeds, but doing same for the destination account fails.

Follow-up PR to #416. This PR fixes many of the problems that we've had in the past related to mutually exclusive Cargo features. In particular, it refactors conditional compilation of the ffi and mock flags into their own separate crates, which allows Cargo to easily avoid conflicts automatically and prepares the ground for fixing #414.

• svm-sdk is split into svm-sdk and svm-sdk-mock. One can easily extern crate svm_sdk_mock as svm_sdk to avoid rewriting lots of examples and tests.
• svm-sdk-host is split into three crates: svm-sdk-host (core trait definition), svm-sdk-host-ffi and svm-sdk-host-mock.
• Same goes for svm-sdk-storage.
• svm-sdk-macros is agnostic to both svm-sdk and svm-sdk-mock with its macros template and template_mock.

Bumps minimatch to 5.0.1 and updates ancestor dependency mocha. These dependencies need to be updated together.

Updates minimatch from 3.0.4 to 5.0.1

Updates mocha from 8.3.2 to 10.1.0

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Overview / Motivation

TODO: Describe the motivation and goals for the issue here...

The Task

TODO: Clearly describe the issue requirements here...

Implementation Notes

TODO: Add links to relevant resources, specs, related issues, etc...

Contribution Guidelines

Important: Issue assignment to developers will be by the order of their application and proficiency level according to the tasks complexity. We will not assign tasks to developers who haven't introduced themselves on our Gitter dev channel

1. Introduce yourself on svm dev chat channel - ask our team any question you may have about this task
2. Fork branch develop to your own repo and work in your repo
3. The code must be formatted using rustfmt
4. You must write unit tests for all types and methods when submitting a component.
5. When ready for code review, submit a PR from your repo back to branch develop
6. Attach relevant issue to PR

Bumps regex from 1.5.4 to 1.5.6.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps crossbeam-utils from 0.8.6 to 0.8.8.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

SVM currently uses BLAKE3 in all places where we need a cryptographic hash function. I believe go-spacemesh uses SHA3, which is quite a bit slower but probably fast enough for our needs. I suggest replacing BLAKE3 with SHA3 everywhere within the SVM so that both the node and SVM can perform account and template address computation using SHA3.