Rust: Borsh and near_bindgen no-std version & no-std smart contract compiled wasm | Bounty: TBD

[mattlockyer]

Disclaimer

This is a big bounty and will likely involve a lot of Rust expertise. Please reach out and comment if you are interested. Bounty value is still TBD

Description

Create a fork/PR of Borsh that is no-std and capable of being used to compile a Near smart contract to wasm.

Context

Currently using create-near-app --rust [name] produces a sample project with a compiled Near smart contract status_message.wasm that is approx 120kb in size.

Goal: decrease the compiled wasm size by making Borsh no-std compatible.

use borsh::{BorshDeserialize, BorshSerialize}; is NOT no-std compatible.
Other details:
use near_sdk::{env, near_bindgen}; is NOT no-std compatible.

You can modify the contract to remove: use std::collections::HashMap;

Borsh:
https://github.com/near/borsh
Near SDK (bindgen):
https://github.com/near/near-sdk-rs
no-std:
https://rust-embedded.github.io/book/intro/no-std.html
The sample rust contract:
https://github.com/near/create-near-app/blob/master/common/contracts/rust/src/lib.rs
Potentially useful:
https://crates.io/crates/no-std-compat

Acceptance Criteria

• [A fork/PR of Borsh that is no-std compatible]
• [A sample contract using no-std & near-bindgen that compiles to wasm]
• [A sample project, e.g. create-near-app that deploys and interacts with the compiled contract]

Bounty

TBD

[luciotato]

do you have an estimated for the bounty value?

[mattlockyer]

Not at this time apologies. We will update this issue when we do. Priorities are ETH bridge at the moment so perhaps check for bounties related to that in the coming weeks.

[frol]

@mattlockyer @nearmax I propose we split the bounty into smaller chunks:

0. identify and exhaustively list the dependencies and the features that cannot be used in no-std/alloc environment for (a) borsh, (b) near-sdk-rs. (will be, essentially, part of the (1) and (2) bounties)
1. implement the base-line no-std support for borsh (e.g. the API could be less ergonomic, yet useful enough to unblock no-std in near-sdk-rs for a minimal contract)
2. Implement the base-line no-std support for near-sdk-rs (e.g. the API could be less ergonomic, yet useful enough to unblock minimal no-std contract)
3. Extend no-std support in borsh to be feature-complete with the current std support (except where we cannot do so)
4. Extend no-std support in near-sdk-rs to be ergonomic (the goal is to have no or minimal changes to the current contracts while shrinking their wasm binary size)

Note, every step should have a measurable impact on the produced Wasm size (the size should go down 😄).

[mattlockyer]

Closing because of this reference implementation of token with no-std:
https://github.com/near/core-contracts/tree/b7dd5e1ba572c853a727dd616d039411f363533a/fast-fun-token

[MaksymZavershynskyi]

@mattlockyer I think this bounty is still relevant. We need no-std support of both borsh and near-sdk-rs for various reasons.

[MaksymZavershynskyi]

Adding the plan on how to implement it:

For both crates would like to add support of no-std similarly to how serde did it:

• Create a separate std feature: https://github.com/serde-rs/serde/blob/master/serde/Cargo.toml#L32
• Condition no_std on absence of this feature: https://github.com/serde-rs/serde/blob/master/serde/src/lib.rs#L87
• Then use this feature to decide what to import: https://github.com/serde-rs/serde/blob/master/serde/src/lib.rs#L151-L249

Specifically for borsh, we would need to release a major version, since it will be non-backwards compatible change:

• We can get rid of borsh-schema-derive-internal to make things easier;
• Then we need to replace std::io::Error, std::io::Writer/Reader, and other std::io types because they are not supported by Rust no_std: Using std::io::{Read, Write, Cursor} in a nostd environment rust-lang/rust#48331 . We would have to define our own error type and potentially replace Writer and Reader by using byte slices directly;
• Finally, we would have to make std-specific implementations available only when std feature is defined: https://github.com/near/borsh/blob/master/borsh-rs/borsh/src/de/mod.rs#L288-L407

Specifically for near-sdk-rs, we might not need to release major version and only release minor version, since it will probably be a backwards compatible change:

• We need to replace usage of thread_local https://github.com/near/near-sdk-rs/blob/master/near-sdk/src/environment/env.rs#L17-L22 with lazy_static crate. We need this line of code to ensure static initialization.

[frol]

borsh-rs has received no_std support: near/borsh#108

@nearmax do we have a team working on no_std support near-sdk-rs? Can we assign them on this issue?

[cameron-NEAR]

@nearmax @frol - did you assign a team to work on this issue / should I close this bounty?

[bowenwang1996]

I think the dev plaform team is already working on this. cc @mikedotexe @austinabell

[austinabell]

I think the dev plaform team is already working on this. cc @mikedotexe @austinabell

Correct. IMO can close this bounty, this is in my current plan and I don't foresee any blockers.