You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thus, the dev (e.g. devs from inno team) should write a lib (for Args) for each language they want to use. This looks also
weird on SC dev side and can make it harder to onboard them on SC developing in Massa.
Another inconvenience is that for now we only support AssemblyScript (for SC development) and we'd really like to support
other languages.
A solution to rule them all (V2)
Warning: here we describe the solution we'd like to have at the end, V1 is what we are going to implement first
On Frontend side
Frontend dev will communicate with Massa node with a GRPC endpoint in order to do a CallSC. Serialization (in protobuf) is already
implemented for many languages (Js, Go, Python).
On SC dev side
The SC developer will now be able to write function like:
import{Args}from'@massalabs/as-types';// Original function (ideally not exported)functionfillarray__(args: Args): Uint8Array{letlen=args.nextU32();letvalue=args.nextU8();
...
}// Generated by the transformexportfunctionfillarray([WITarguments]): [WITreturn]{
let args=Uint8array::FROM_WIT_ARGUMENTS;// pseudo codeletreturn=fillarray__(args);returnWIT_RETURN(return);// pseudo code}fnmain(...): ... {let args = ...;// transform patch this call from fillarray(args) to fillarray(__args)fillarray__(args)}
And so we have the opportunity to:
Develop SC with Rust (Need Args like lib, wit/wai file to write manually)
Test cross SC call (e.g. AS SC calling another functions in Rust SC)
This is way simpler than V2 because the transform is already partially implemented +
we keep the compatibility with what is avail. now (e.g. Args)
V2 with technical details
Frontend side
Given the following .proto file (and thanks to Any):
Note: a decorator like @grpc or @extern could be provided if we want user control over this.
By using a transform, the resulting code will be:
// Original function (ideally not exported)functionfillarray__(len: u32,value: u8): Uint8Array{letlen=args.nextU32();letvalue=args.nextU8();
...
}// Generated by the wit transformexportfunctionfillarray([WITarguments]): [WITreturn]{letargs=FROM_WIT_ARGUMENTS;// pseudo codeleta=args_.a;letb=args_.b;letreturn=fillarray__(a,b);// call original functionreturnWIT_RETURN(return);// pseudo code}// Generated by the grpc transform (depending on decorator @grpc?)exportfunctionfillarray_PROTOBUF(args: Uint8Array): Uint8Array{letargs_=DECODE_PROTOBUF(args);// pseudo codeletlen=args_.len;letvalue=args_.value;letreturn=fillarray__(len,value);// call original functionreturnENCODE_PROTOBUF(args);// pseudo code}fnmain(...): ... {let args = ...;// transform patch this call from fillarray(args) to fillarray(__args)fillarray__(args)}
Note:
This requires a wit transform handling all types supported by WIT (Long term & not so easy task to do)
Cross SC call
TODO: what if the SC dev user want to restrict the args size (which will be below MAX ARGS size const in Massa const)
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Intro
In our current Smart Contract (SC) implementation, we face 2 problems:
Understanding these issues for SC dev & Frontend (or Thyra) devs
A SC developer (in Assembly script) instead of writing this
will have to write:
And the other side, a frontend dev in order to call the
fillarray
(as previously defined), will:Thus, the dev (e.g. devs from inno team) should write a lib (for Args) for each language they want to use. This looks also
weird on SC dev side and can make it harder to onboard them on SC developing in Massa.
Another inconvenience is that for now we only support AssemblyScript (for SC development) and we'd really like to support
other languages.
A solution to rule them all (V2)
Warning: here we describe the solution we'd like to have at the end, V1 is what we are going to implement first
On Frontend side
Frontend dev will communicate with Massa node with a GRPC endpoint in order to do a CallSC. Serialization (in protobuf) is already
implemented for many languages (Js, Go, Python).
On SC dev side
The SC developer will now be able to write function like:
By using a common Memory layout for WASM (aka Wit), we could support Rust written Smart contract thus writing:
V1
Args should still be used (on both side), the only difference is by using the Wit memory layout.
SC dev will write:
By using a transform, the resulting code will be:
And so we have the opportunity to:
This is way simpler than V2 because the transform is already partially implemented +
we keep the compatibility with what is avail. now (e.g. Args)
V2 with technical details
Frontend side
Given the following .proto file (and thanks to Any):
It can be used in any lib/programming language that support grpc/protobuf.
A good inspiration (maybe for code reuse), is available here.
SC side
SC dev will write:
Note: a decorator like
@grpc
or@extern
could be provided if we want user control over this.By using a transform, the resulting code will be:
Note:
TODO: what if the SC dev user want to restrict the args size (which will be below MAX ARGS size const in Massa const)
@grpc(max_size = "500k")
A Rust SC will be more like:
The massa bindgen proc macro will auto generate the function
fillarray_PROTOBUF
.Beta Was this translation helpful? Give feedback.
All reactions