search

filecoin-project / devgrants

👟 Apply for a Filecoin devgrant. Help build the Filecoin ecosystem!
Other
376 stars 308 forks source link

RFP Application: FVM - AssemblyScript SDK #582

Closed ainhoa-a closed 2 years ago

ainhoa-a commented 2 years ago

RFP Proposal: FVM - AssemblyScript SDK

Name of Project: FVM - AssemblyScript SDK

Link to RFP:

RFP Category: devtools-libraries

Proposer: ainhoa-a

Do you agree to open source all work you do on behalf of this RFP and dual-license under MIT, GPL, and APACHE2 licenses?: Yes

Project Description

In the context of the FVM Early Builder program, we propose to build a set of tools to facilitate the use of AssemblyScript to write new smart contracts that will be compiled to WASM code at the end. WASM is what FVM uses to run smart contracts.

Nowadays, there are two SDKs for FVM smart contracts: Go and Rust. However, none of these languages is as popular and widely used as Javascript. AssemblyScript is part of the Javascript/Typescript family but it compiles to WASM.

To contribute to the growth of the ecosystem, it would be valuable for FVM to allow users to write smart contracts using this language.

Development Roadmap and Deliverables

Phase 1

Milestone 1 - Deep dive into the FVM / Growing the filbuilders community

Assumptions/Pre-Requirements

Technical Scope

A tentative list of functions would be the following ones.

Deliverables:

Funding for this Milestone 36.000,00- $

Estimated Milestone Delivery End of June 22

Milestone 2 - With AssemblyScript to to hell and back - The sky is the limit

Assumptions/Pre-Requirements

This phase requires a close collaboration with the Assemblyscript team; it would also be valuable to collaborate with NEAR (they are pioneers in this area). A detailed planning of meetings shall be agreed at the project setup.

Development of additional libraries (eg. c-bor library for storage) and access to certain resources is required.

The availability of these pre-requirements is mandatory to acomplish the Milestone 2. A close collaboration between the parties may avoid any delay.

Technical Scope:

Deliverables:

Both data structures and utilities packages:

Funding for this Milestone 42.000,00- $

Estimated Milestone Delivery End of August 22

Total Budget Requested for Phase 1

Total: 78.000,00- $

Estimated delivery overview

Future development and Upgrade Plans Phase 2

We would like to continue with further development after M2, but this is out of scope for this proposal. This should be agreed either at a later time or in the frame of another program. The experience we will earn during Phase 1 will help us to better refine the Scope of Phase 2.

Team

Contact Info and Team Members

As we are a team of over 20 engineers at Zondax, more members may be added later if support or specific skills are needed.

Team Website

https://zondax.ch/

Relevant Experience

We have been collaborating with PL for several years and have/or are currently contributing to the following projects: Signing Tools (WASM/Typescript and FFI support, Secp256k1 and BLS support) Filecoin Indexing, Filecoin GPU Scheduler, Exchanges & Custodian technical support among others.

Team code repositories

https://github.com/Zondax

Additional information

We would like to be part of this program in order to:

This aligns with our willingness to work towards fully decentralized networks, collaborate with Blockchain cost-effective solutions and build Interoperability standards that are key to foundational protocols.

ainhoa-a commented 2 years ago

Hi @BlocksOnAChain, as discussed, here the RFP draft proposal.

BlocksOnAChain commented 2 years ago

@ainhoa-a - This looks ok to me in terms of project scope, milestones, and funding. We just need to add more numbers to get a real feel about it. Would love if we can get some comments from @raulk as a tech lead and @DeveloperAlly as our FF representative + our amazing dev rel person

BlocksOnAChain commented 2 years ago

@ainhoa-a do we plan to add funding numbers - I see that "Funding for this Milestone" sections are still TBD.

BlocksOnAChain commented 2 years ago

@ainhoa-a is the draft in final stages of updates from your side, would like to move into final reviews, if you are happy with the current state of the proposal?

ainhoa-a commented 2 years ago

Hi @BlocksOnAChain, as we are not requesting any budget at the moment for Phase 2 and the scope for later developments will be better estimated after Phase 1 I have removed for clarity that section.

Stebalien commented 2 years ago

Phase 2 looks like a good next step. I'd consider adding some form of wallet or multisig actor to the example application list as that will test sending messages, authentication, etc.

Base64 codec

This seems a bit out of place (filecoin doesn't really use base64 anywhere and there's already a base64 library for AS). What's the motivation?

Common maths operations for FVM

I assume you mean a bigint library. Note: most token computations can be done in u128 if you're careful, but a bigint library would be nice.

Create data structures using FVM basic methods: arrays, maps, queues.

I.e., libraries for the builtin actor's HAMT, AMT, etc?

Technical scope

The current sdk requires a lot of manual work to decode/encode CBOR. I would consider implementing a codegen tool to reduce the boilerplate (to save you time and misery if nothing else).

BlocksOnAChain commented 2 years ago

@ainhoa-a would be great if your dev team representative can respond to the latest comment that @Stebalien made, since I find it relevant for the overall approval of the proposal: https://github.com/filecoin-project/devgrants/issues/582#issuecomment-1171923773

ainhoa-a commented 2 years ago

Hi @BlocksOnAChain, the team is looking into those comments and we will respond shortly.

ainhoa-a commented 2 years ago

Hi @Stebalien here our comments.

Phase 2 looks like a good next step. I'd consider adding some form of wallet or multisig actor to the example application list as that will test sending messages, authentication, etc.

This is not fully defined yet, and we would be happy to define this together in a new proposal before completing Phase 1, but we agree, wallet or multisign support sounds exciting!

Base64 codec

This seems a bit out of place (filecoin doesn't really use base64 anywhere and there's already a base64 library for AS). What's the motivation?

We noticed this in other smart contract platforms and thought it could be useful. But if it is not relevant we can remove this and substitute it with other things we recently noticed would be more useful like improving tooling, adding more examples and benchmarking.

Common maths operations for FVM

I assume you mean a bigint library. Note: most token computations can be done in u128 if you're careful, but a bigint library would be nice.

Here we are referring to making things simple and creating examples, documentation and tests, not a bigint library, as this would be a project on its own with higher risks.

Create data structures using FVM basic methods: arrays, maps, queues.

I.e., libraries for the builtin actor's HAMT, AMT, etc?

No, we're not referring to HAMT, AMT. Our idea was more on arrays or maps that are automatically saved on the blockchain, but we won't need this anymore, as we have recently considered a different approach. AS has built-in support for arrays, maps etc.

Technical scope

The current sdk requires a lot of manual work to decode/encode CBOR. I would consider implementing a codegen tool to reduce the boilerplate (to save you time and misery if nothing else).

We will optimize this along the way, and we have now learnt how to efficiently use existing bgint and cbor.

Stebalien commented 2 years ago

So, I want to make sure there's a usable deliverable. At the moment, the main deliverable is a 0.2 SDK, but I'm not sure what it will actually support.

This is not fully defined yet, and we would be happy to define this together in a new proposal before completing Phase 1, but we agree, wallet or multisign support sounds exciting!

My concern is that I can't see how any of the other "advanced examples" will involve sending messages from one actor to another on-chain. If this case is already covered by one of the examples, I then there's no need to include this in Phase 1. Otherwise, I'd like that functionality to be tested somehow given that it's in-scope.

Basically, I want there to be a complex enough example to validate the SDK. Testing things like:

We noticed this in other smart contract platforms and thought it could be useful. But if it is not relevant we can remove this and substitute it with other things we recently noticed would be more useful like improving tooling, adding more examples and benchmarking.

Yeah, I don't think it's particularly useful or relevant. I wouldn't bother with it given that alternatives exist and it's not FVM specific.

Here we are referring to making things simple and creating examples, documentation and tests, not a bigint library, as this would be a project on its own with higher risks.

I'm confused, what's the output here? I can get basic math examples from https://www.assemblyscript.org/.

No, we're not referring to HAMT, AMT. Our idea was more on arrays or maps that are automatically saved on the blockchain, but we won't need this anymore, as we have recently considered a different approach. AS has built-in support for arrays, maps etc.

But you're currently doing that, right? With CBOR? A more useful feature would be to generalize CBOR support to have something like the system we've built in the builtin actors (where you can serialize arbitrary datastructures). Building a one-off demo that can serialize a basic map/array doesn't get us any closer to a usable AssemblyScript SDK.

Stebalien commented 2 years ago

Ah, sorry, I said "Phase 2" but I was referring to "milestone 2".

Stebalien commented 2 years ago

To summarize, I can see the deliverable, but I'm having trouble figuring out how to measure success (or what success even looks like).

The example contracts are really helpful, but it's hard to tell how these examples will drive the SDK. Technically, I'm pretty sure these examples can all be implemented today without any changes to the SDK, although changes to the SDK would make them significantly easier to implement, and cleaner.

ainhoa-a commented 2 years ago

Hi @Stebalien I have updated both Deliverable sections adding more details on what is covered.

Stebalien commented 2 years ago

@ainhoa-a that really helps, proposal LGTM.

In the next milestone I'd really like to see:

ainhoa-a commented 2 years ago

Thank you @Stebalien, will take this into account for the next Phase.

BlocksOnAChain commented 2 years ago

@ainhoa-a now that we have approval from @Stebalien, I was just wondering if we have some final thoughts from @raulk, before we go for the grant approval?

raulk commented 2 years ago

This looks great! Personally I would like to see the following:

  1. Two or three more example actors, with different levels of sophistication. Basically use these actors to showcase different features of the SDK (and plan that ahead of time which actors will cover which features, to make sure everything is covered).
  2. Example feature snippets in the SDK docs and in the SDK codebase, e.g. examples/cross-actor-calls, examples/state-write, examples/error-handling.

Basically the goal is to remove friction between the time folks discover this SDK and they start working with it. You mentioned above that you'd take richer examples into account in the next phase, but I really do think they belong in this phase because they shape the first impression that devs will get.

Other than that, please consider this pre-approved. If you're able to add the above to this phase, I'd be happy. If not, I can settle ;-)

ainhoa-a commented 2 years ago

Hi @raulk thank you for your feedback.

I have updated the proposal under Milestone 2 to include feature snippets including at least the ones you mentioned examples/cross-actor-calls, examples/state-write, examples/error-handling.

As per the example actors, we will cover different levels of sophistication, and we plan to include cross-actor-calls in the FNS example, state-write in the Hello world etc.

ErinOCon commented 2 years ago

Hi @ainhoa-a, this grant has been approved! Can you provide a preferred email address to proceed with next steps?

ErinOCon commented 2 years ago

Thank you!