RFP Application: FVM Native Toolset

[tchataigner]

RFP Proposal: FVM Native Toolsed - Kythera

FVM Native Toolset - Kythera

RFP Category: devtools-libraries

Proposers: @tchataigner @PhilippeMts

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

Project Description

Abstract

When dealing with the development of smart contracts (or actors per Filecoin lexicon), developers have to go through multiple stages before safely deploying their code. Typically an actor developer would evolve through 3 different environments:

• Development environment: Most likely located on a local machine, the development environment provides a sandbox where the developer can safely experiment and unit test the different features that are supposed to be delivered.
• Staging environment: In dApp development the staging environment is usually referring to a testnet where the conditions of the network are emulated to behave the same as the mainnet.
• Production environment: Commonly referred to as the mainnet, this is where the developed actor will be deployed to be available to any client.

The goals of the FVM Native Toolset are to ease the development stage for the developer by bringing an FVM-compatible execution environment and libraries for testing utilities, and facilitate the transition to the staging and production environments.

Motivations

A strategic resource

With the release of milestone 2.1, it will be possible for Ethereum smart contract developers to try out the capabilities of the FEVM. The choice to first release the FEVM, cashing on the Ethereum ecosystem and its maturity, might allow for smooth adoption.

However, the FEVM has one limitations, it limits a developer in only imagining applications limited to the EVM context while WASM-based actors open-up new possibilities.

But for these possibilities to exist, the ecosystem of native actors is in need of tooling on par with the Ethereum ecosystem. We think that a toolset is the first key component for developers as it allows for experimentation over use cases and a consolidation of code bases reliability. Developing such a solution would also prove useful in organizing hackathons, and allowing developers to directly dive in their actors’ implementation.

As such a component is a strategic resource for the Filecoin ecosystem, we believe that a team like Polyphene could be the right one to handle its specification and development.

Dedicated team

At Polyphene, we started to navigate in the IPFS/Filecoin ecosystem two years ago.

Our first project, Holium, leveraged IPFS and IPLD schemas to create a protocol that allowed data scientists to declare, share and execute data pipelines in a decentralized fashion. The first release of the protocol at the end of 2021 sparked up some early discussions with the FVM core team to try and consider potential collaborations.

Encouraged to apply to the Early Builders Program (EBP) in early 2022, we became one of the first teams to tinker with the early iterations of the protocol, assisting the development of the core team and trying out actors development.

During the P0 of the program, we notably:

• designed and developed the first version of the integration test framework, a tool that proved necessary in testing out specification and implementation alignment for the virtual machine.
• sketched and implemented an early version of a native Rust SDK to ease native actor’s development, based on the FVM core team suggestions and the community proposals.
• assisted and mentored any new member of the program in acquiring a sufficient knowledge base to navigate through the protocol implementation.

Those experiences helped us create deep connections with the historical members of the EBP and the engineers of the FVM core team. Those connections would help us in a new toolset development by allowing us to easily reach out to the community for feedbacks and craft a solution handmade for both the native actors developers and the core team.

Inspirations

When looking at solutions over different ecosystems for toolsets, there are a few candidates that the FVM Native Toolset should get inspiration from. In the following section we go over some potential inspirations and their strengths.

Ethereum - Hardhat

The Hardhat project from the Ethereum ecosystem is a great example of a simple toolset, focusing on providing users with a complete, yet simple, testing environment.

There are two main components for the project, Hardhat Runner and Hardhat Network.

Hardhat Runner is the main component that users interact with and contains most of the logic related to smart contracts development, like compilation, testing and deployment. Hardhat Network on the other hand provides a local Ethereum network node designed for development.

Tests development and management is done through JavaScript or Typescript. Hardhat provides its own set of Chai matchers to help design test cycles that are as DRY (Don’t Repeat Yourself) and self-documented as possible.

One of the key strength of Hardhat comes from its plugin system. The Hardhat Runner comes with a set of built-in tasks (compile , run , test …). Plugins can be created by users to compose with built-in tasks or even overwrite them. Another interesting feature is the existing integration with the template system, Open Zeppelin. By installing the npm package handed out by the Open Zeppelin team, it is possible for developer to easily refer to a template contracts in their solidity code (e.g.: import "@openzeppelin/contracts/token/ERC20/ERC20.sol" ).

Ethereum - Foundry

Foundry is another toolset from the Ethereum ecosystem. It is more recent than Hardhat and tries to fill the caveats of its senior. Where Hardhat focuses on simplicity, Foundry proposes a more complex but richer solution for testing.

When installing Foundry, three components are made available: forge, cast and anvil.

Forge is the testing framework, like Hardhat Runner. It handles the compilation and testing for smart contracts development. Advanced features goes from fuzzy testing to generating gas reports for a contract. Cast is the command-line interface (CLI) for performing Ethereum RPC calls to make smart contract calls, send transactions, or retrieve any type of chain data. Anvil is the local Ethereum network node, like Hardhat Network.

Tests are written in Solidity, testing utilities are available through smart contracts that can be imported in the test contracts.

The strength of Foundry is its compilation speed, attained through a solid caching system and parallel compilation. Along with the compilation speed, Foundry allows for fast test development thanks to their Solidity-based approach.

Solana - Anchor

Anchor’s toolset has emerged for the Solana ecosystem. Its goal is to provide convenient developer tools for writing smart contracts compatible with the Solana chain.

Anchor could be a great inspiration with their technical architecture and implementation. They leverage Rust and macros to facilitate development of programs.

The toolset testing is handled through JavaScript or Typescript.

Deliverables

The toolset will provide:

• A local execution environment to emulate the FVM deployed on chain.
• A testing framework to assist a developer in designing, debugging and securing actors.
• A templating system, allowing for any developer to jump into the development of actors.

The toolset, to fit into the technical choices made by the FVM team, will be developed using the Rust language.

Local execution environment

A developer has to be able to boot a local execution environment to deploy and test actors. This execution environment should be working hand-in-hand with the testing framework covered in the next section.

The environment has to be created with a debugging-focused mind, allowing for a smooth developer experience. As such, it should:

• Enable gas tracking for the actors that are being developed.
• Be verbose enough to allow for inspection of the traces produced during a transaction.
• Allow for actors state manipulation to simulate edge cases.
• Allow to fork an existing network state to proceed with testing over the composability with other previously-deployed actors.

Testing framework

The testing framework is heavily inspired from Foundry. Developers should be able to write their tests with any language that can be compiled to Wasm for the FVM. This ensures more adoption and removes the need for developers to learn a new language to handle testing.

Along those lines, the testing framework should:

• Leverage existing compilation capabilities of Rust, Assembly Script and Golang to allow for actor and test development in those languages.
• Have testing utilities that enable the emulation of the widest variety of situations over an actor (inspiration drawn from Foundry’s cheatcodes).
• Be verbose enough to relay traces from the execution environment if needed.
• Allow for debugging, logging and deep inspection of an actor’s state.
• The testing framework should be pluggable, allowing for external developers to easily create new utilities.
• Allow for verifiable builds inspired from Anchor's implementation

Moreover, there is also a need to handle deployment of actors to any external network (testnets and mainnet). As such, we propose to integrate within the test framework a simple command to deploy actors over external networks (testnets or mainnet), inspired from Foundry’s cast.

Template system

To allow developers to quickly start the creation of a project on the Filecoin network, a template system should be created.

This template system should leverage existing initiative of actors standard repository over Github.

Milestones

Milestone 1: Sandbox & basic testing framework

Milestones n°	Name	Description	Time estimation (workdays)
1.1	Local execution environment	A functional local execution environment that would emulate the working environment of the Filecoin network.	20
1.2	Testing utilities	First step of the testing framework, utilities should be created over the execution environment to facilitate testing of actors. Pluggability should be ensured over the testing utilities.	18
1.3	Connection to external network	It should be possible to deploy an actor over an external network (testnets or mainnet).	8
			Total: 46 workdays

Milestone 2: Testing framework improvement

Milestones n°	Name	Description	Time estimation (workdays)
2.1	Debugging and logging	A developer should be able to include logging commands in actors sources.	8
2.2	Gas usage	A developer should be able to inspect gas consumption from its actors	15
2.3	Verbose traces	A developer should be able to setup its environment to inspect stack call traces at execution time.	10
2.4	Actors’ state manipulation	To allow for edge cases testing, a developer should be able to directly manipulate an actors state at run time.	15
			Total: 48 workdays

Milestone 3: External network interactions and template system

Milestones n°	Name	Description	Time estimation (workdays)
3.1	Template	A minimal template system should be created, to pull templates from a designated GH repository.	8
3.2	Use external network state in local execution environment	A developer should be able to fork an existing network state in its local execution environment.	13
3.3	Assembly Script, Rust and Golang compatibility	The testing framework should be working with actors written in all three languages.	15
3.4	Verifiable builds	The testing framework should be providing a sandbox for compilation environment in the shape of a Docker image	16
			Total: 52 workdays

Combined milestones workdays

Estimated workdays: 146

Funding

A developer workday at Polyphene is quoted at $1500, thus our quote amounts to:

Original quote

146 * 1500 = $219 000

Applying 10% discount

Final pricing: $197100

Right now, it would be needed for the Polyphene team to hire a developer to have a complete team of 3 people working on the project. To start this process as soon as possible Polyphene is asking for an upfront payment. We propose to split the funding in three steps:

Funding steps	Event	Funding percentage
0	Signature of the RFP	20%
1	Milestone 1 delivered	25%
2	Milestone 2 delivered	25%
3	Milestone 3 delivered	30%

Gantt Chart

Maintenance

The Polyphene team will handle any bug fixing needed over the code base or any documentation update at Polyphene’s discretion.

The maintenance proposed in this RFP would not be applicable for any desired upgrades or feature improvements. These concerns should be addressed at a later stage of the project, when milestone 2 is delivered.

Team

The size of the project and its significance for the ecosystem creates a strong need for a dedicated team to handle the development.

A team of 3 developers will be provisioned to ensure a continuous development.

Once milestone 2 is reached, the team should expand to a part-time product manager. Taking care of communication between developers of the toolset and the rest of the community, their role will focus on the improvement for developer experience.

[maciejwitowski]

Thank you for the proposal, I really like it!

Some early thoughts:

1. Did you think about providing the website with the documentation? I didn't see it mention so just want to make sure it's in the scope.
2. About local environment: You said that it "would emulate the working environment of the Filecoin network". Assuming many dapps build on Filecoin will interact with the Filecoin built-in actors APIs, how can we make this experience is great on local env? This is different comparing to other Ethereum-like networks, where dapps don't interact with the protocol.
3. About external environment: I think it would be great if we organised milestones in a way that we have PoC of deploying contracts to test network like Wallaby early. If possible I'd consider adding it as Milestone 2. Reasons
   • Devs (even us, at core team building actors, doing smoke tests for releases etc) would start discovering issues and give feedback early
   • There will be early builders program where people will be excited to build and ship anything to the public network so having a tool would be helpful
   • I'm afraid devs won't be so interested in trying it on the local env for too long
4. I wonder, should we consider switching milestones 3.1 and 3.4 so we focus on end-to-end developer experience with Rust first before diving for 3 weeks into supporting more languages? (of course it'd be great to have a solid high-level idea for how these languages will be supported)
5. About: "Assembly Script, Rust and Golang compatibility" - would this support be in the program, or will there be some kind of plugin systems so more languages compiled to WASM can be added later?
6. You mentioned plugin system in Hardhat. Is that something you're planning as well? I think that the ability to extend a tool like this is really important.
7. Just making sure: will calls between actors be supported?
8. Anchor supports verifiable builds via docker. I'm wondering how important it is to support them from the beginning. Wdyt?

[tchataigner]

Thanks for the feedback @maciejwitowski !

1. Did you think about providing the website with the documentation? I didn't see it mention so just want to make sure it's in the scope.

You’re right, we propose that the documentation takes the shape of a markdown-based static website (like MkDocs, Docusaurus …).

Documentation will be updated each time a sub-milestone is delivered. We will make sure that the documentation is properly done and comprehensive by asking community/core team for feedback on a milestone delivery.

2. About local environment: You said that it "would emulate the working environment of the Filecoin network". Assuming many dapps build on Filecoin will interact with the Filecoin built-in actors APIs, how can we make this experience is great on local env? This is different comparing to other Ethereum-like networks, where dapps don't interact with the protocol.

Built-in actors can be emulated in our local environment as their API and build are available on Github. We can mock behaviors as it was done for some of the internal testing utilities of ref-fvm.

3. About external environment: I think it would be great if we organised milestones in a way that we have PoC of deploying contracts to test network like Wallaby early. If possible I'd consider adding it as Milestone 2. Reasons:
   • Devs (even us, at core team building actors, doing smoke tests for releases etc) would start discovering issues and give feedback early
   • There will be early builders program where people will be excited to build and ship anything to the public network so having a tool would be helpful
   • I'm afraid devs won't be so interested in trying it on the local env for too long

Good considerations, deployment should then be moved up to Milestone 1.

4. I wonder, should we consider switching milestones 3.1 and 3.4 so we focus on end-to-end developer experience with Rust first before diving for 3 weeks into supporting more languages? (of course it'd be great to have a solid high-level idea for how these languages will be supported)

Switching them. When getting to this stage of development the precise specifications should be laid out so there should be no problem to anticipate the integrations

5. About: "Assembly Script, Rust and Golang compatibility" - would this support be in the program, or will there be some kind of plugin systems so more languages compiled to WASM can be added later?

Our idea is to have an interface that would in each language that would rely on syscalls logic for the testing utilities that can be accessible for the testing framework and the sandbox. So adding the possibility for more languages would most likely be encompassed to creating this interface and adding compilation options for projects in the program.

6. You mentioned plugin system in Hardhat. Is that something you're planning as well? I think that the ability to extend a tool like this is really important.

We did not consider building a fully functional plugin system for this RFP. We wanted to focus on providing a code base that would be easily extended and some documentation on how to do so. Do you think we should consider such a system at this first stage ?

7. Just making sure: will calls between actors be supported?

Yes it is, we are aiming to be compatible to project that will focus on multiple actors development or composability with other dApp. Specifications will be drafted in that regard.

8. Anchor supports verifiable builds via docker. I'm wondering how important it is to support them from the beginning. Wdyt?

****Verifiable build****

Interesting proposition! We could create a more isolated environment in a Docker container to build projects and access their artifacts. I will add it in milestone 3.

It has to be noted that it won't be a perfect verification though. Docker containers are by definition non-deterministic so build output might differ.

[BlocksOnAChain]

@tchataigner thanks for this, looks really good. 👍 I'm glad we spent some extra time on it to cover the entire scope of the proposal, now we can really enjoy seeing how far we came from the early draft days.

Next to all the comments from @maciejwitowski that you addressed, I would like to know more about:

• I love that we included the sandbox in the scope, but as you already know this is something that can go in many different directions/approaches... It would be great if you can add more details about it - what is the actual layer where the simulation will take place and how would that work from a development experience perspective?

Also, 1 thing I would like to point out is the information I have - we have a lot of humans thinking about the future of the "Local execution environment" so we would expect you to work with them to coordinate and deliver this epic according to the needs of all FVM builders, including the ability to support core dev needs for builtin actors. Good next step: I think talking to @anorth and seeing what his plans are + keeping an eye on what else we are building for this would help us solve this user path in the best way possible. It would also give you the ability to re-use some of the parts we created on the PL side.

[tchataigner]

Reached @anorth on Slack where other useful resources were shared. We are currently parsing through them to make sure we did not miss anything and come up with a detailed proposal.

We also had discussions about the pricing which led us to apply a 10% discount on our original prices because of the interest we have in building such a tool, the length of the mission, and our past experience in working with the Filecoin Foundation and Protocol Labs teams. Updating the RFP to reflect this.

[BlocksOnAChain]

@realChainLife - this RFP is ok to approve from my side, I think we have a consensus in the FVM team to approve this line of work. I will put it in the correct status for your review and final approval.

CC: @raulk @maciejwitowski for visibility

[ErinOCon]

Hi @tchataigner, thank you again for your proposal and for the additional information provided to our team! We will circle back once our review is complete.

[tchataigner]

Hey @ErinOCon and all ! First off, Happy New Year full of hapinness :tada: I was messaging back to know if there was anything we could do on our end to ease the process. If that is the case please let us know !

[ErinOCon]

Hi @tchataigner, happy new year to you, as well! There was a hold on our review through the holidays. We expect to have more information available early to mid-January.

[BlocksOnAChain]

We can close this RFP, since the polyphene team did all the work on M1 and M2. Another team will do M3 in the future.