Agenda for 7/15/21 sync about Rust SDK

meeting-notes.md

Opening

• Is there a reason for no_std or is this synonymous with the goal of reduce contract size.
• What's the criteria we're aiming for, which types of contracts are being built that the SDK is not optimized for.

What does an existing contract look like

• Is it like Eugene's approach? (near/core-contracts#88 also more readable here: https://github.com/near/core-contracts/blob/882ded0634ee50ef134a82c1bbf53262ab8b1550/fast-fun-token/src/lib.rs)

Peek into the link above:

…
#[allow(unused)]
extern "C" {
    // #############
    // # Registers #
    // #############
    fn read_register(register_id: u64, ptr: u64);
    fn register_len(register_id: u64) -> u64;
    fn write_register(register_id: u64, data_len: u64, data_ptr: u64);
…
#[no_mangle]
pub unsafe fn init() {
    if storage_has_key(SUPPLY_KEY.len() as _, SUPPLY_KEY.as_ptr() as _) == 1 {
        panic();
    }
    let buf = read_input();
    // SUPPLY_KEY
    storage_write(
        SUPPLY_KEY.len() as _,
        SUPPLY_KEY.as_ptr() as _,
…   

Short-term

• Are there midway solutions to provide gains to discuss? For instance, using miniserde instead? https://crates.io/crates/miniserde
• Other solutions we should know about?

Future thoughts / findings

• Talk about Austin's findings for rlib (NEAR Inc. Slack thread: https://near--inc.slack.com/archives/C025F493T2R/p1625786672027100)

• Building a foundational layer for the SDK: near/near-sdk-rs#463

  Intro statement from Kladov for context:

  Our current SDK is pretty high-level and opinionated -- is presupposes borsh serialization, strongly-typed wrappers for types, etc. While it is a great fit for the average use-case (or at least aspires to be one), one size doesn't fit all!

  It might be useful to publish unopinionated subsets of the SDK, which just give bindings to the system APIs, but don't prescribe any particular style of contracts.

• Austin's work on "nesdie" here: https://github.com/austinabell/nesdie, we talk about what it is and isn't.

  [nesdie] is just meant as an experimental SDK which will follow similar patterns of near-sdk-rs but optimize for minimal code size and operations. This will be a worse devX than the near sdk, but can be used as an alternative to writing bare metal contracts without an SDK.

Meeting notes captured here: near/community#76