Closed tchataigner closed 1 year ago
Thank you for the proposal, I really like it!
Some early thoughts:
Thanks for the feedback @maciejwitowski !
- 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.
- 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
.
- 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.
- 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
- 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.
- 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 ?
- 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.
- 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.
@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:
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.
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.
@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
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.
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 !
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.
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.
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:
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:
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:
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:
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:
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
Milestone 2: Testing framework improvement
Milestone 3: External network interactions and template system
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:
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.