RFP Proposal: Filecoin-solidity: Optimization, Improvement, Maintenance by MVP Workshop

[alexdimitrijevic]

RFP Proposal: Filecoin-solidity improvement & maintenance

Name of Project: Filecoin Solidity Optimization

Link to RFP: https://github.com/filecoin-project/devgrants/blob/master/rfps/Filecoin-solidity-Optimization.md

RFP Category: devtools-libraries

Proposer: alexdimitrijevic

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

In the context of improving current Solidity libraries for Filecoin, we propose to build a set of tools and libraries to enable Ethereum developers to re-use their existing know-how to develop Filecoin-specific use cases.

Development Roadmap

The developer roadmap has been divided into three milestones, a milestone per each epic from the original RFP.

Milestone 1 - Compatibility with compiler optimizers

During these 3 weeks, we will focus on making the filecoin-solidity library compatible with all types of optimizers, including Standard, YUL, and –via–ir optimizers. We will also set the EVM Version property of the Solidity compiler to paris, to prevent any issues with versions 0.8.20 and above, regarding the PUSH0 opcode.

We will not modify any of the tests, to ensure that after optimizations and code changes, the library works as expected, security remains the number one priority.

Deliverable:

• Ensure that each part of the library, and contracts using the library, can be compiled with any type of Solidity compiler optimizer, regardless of the framework and/or dev setup
• Close the issue #295
• Set EVM Version to paris

Milestone 2 - Implementing backlog items

During these 12 weeks we will close all of the issues from the backlog. For each of these, the estimated time is stated in the Deliverables section below. The work on each issue will be separated by opening draft PRs for tracking the progress. The minimum allocation time is 1 week because we are aware that PRs need to be reviewed, and there is a possibility of some requests for changes during the process.

Deliverable:

• Enable read-only “view” methods for protocol accessors (3 weeks)
  • Refactor callByAddress and callByID functions to be read-only (declared as view)
  • Make sure that delegatecalls on contracts using Actor.sol are possible, a.k.a test with various different Solidity Proxy Mechanisms
  • Close the issue #368
• Propagate exit codes (4 weeks)
  • Add proper error handling from precompiles instead of just reverting from library
  • Close the issue # 363
• Add toEthAddress functionality in FilAddresses.sol util (1 week)
  • Implement a function which converts Fil Address to Eth Address. Based on the current implementation, it can be done by slicing first two bytes, something like this filecoinAddress[2:]
  • Close the issue # 342
• Constructors for types (1 week)
  • Close the issue # 319
• Compile params automatically from ABI on rust tests (1 week)
  • Refactor integration tests to encode input parameters using Rust web3 package instead of manual encode of inputs
  • Close the issue # 212
• Add tests to compile libs with many solidity compilers (2 weeks)
  • Refactor config files to include multiple versions of Solidity compilers for compilation instead of sticking with 0.8.17, with particular focus on versions 0.8.20 and above.
  • Close the issue # 187
• Create a table in the README with all the networks the lib has been tested on (1 week)
  • Refactor the README file to include necessary, up to date, deployment information
  • Close the issue # 128
• Refactor project structure
  • This one can potentially depend on your input about the structure, but it should last no more than 1 week
  • Close the issue # 116

Milestone 3 - Developer ergonomics

In these 4 weeks we will focus on implementing all items from the original RFP under the Developer ergonomics epic. Besides that, we will work on improving overall documentation of the library by focusing on more accurate and detailed documentation of functions following the widely adopted NatSpec format.

Deliverable:

• Codebase refactoring following guidance from the Developer ergonomics epic
• NatSpec and overall documentation improvements

Milestone 4 - MAINTENANCE

Upon the finish of first three milestones (a total of cca 19 weeks), we ought to keep the activity of one part-time FTE for at least 4 months with a goal to provide more value to the project.

Deliverables:

• Producing tests for the source code
• Network or core tech (VM) upgrades
• Provide support in keeping the backlog of future improvements alongside FLC community
• Provide support in defining new requirements from core FVM team

Milestone 5 - Bytecode & Gas optimization

Per consultation with the Tech team assigned to the project, the final output and proposal would be that MVP workshop team expresses great interest upon facing the challenge of reducing bytecode size and gas fees optimization.

However, due to the complexity of the requirement, as well as the current overview of the project, we can commit to a monthly end-to-end development starting with a minimum of 1 FTE assigned half-time to the project.

We'd stay open in consulting with the Community + Core team regarding prioritization or overall structure/phasing of this Milestone as a part of this RFP (Filecoin-solidity: Optimization, Improvement, Maintenance) throughout the maintenance of the project, upon delivering Milestones 1-3.

Deliverables:

• The reduction of bytecode size & optimization of gas fees upon completing Milestones 1 & 2

Project estimation & Team structure

MVP Workshop plans to assign a dedicated team of 2 (two) Senior Smart Contract & Solidity Engineers, with knowledge of low-level programming, Yul, Go & Rust.

The development team commits on delivering:

• Milestone releases per proposed schedule in the form of new code, and existing code improvements
• Opening a draft PR for each part of the work, marking PR ready for review upon completion, and follow-up in case there is a need for changes of any kind
• Future Maintenance if needed

In addition to that, the Leadership team will assign a Project Lead for this project, which would work alongside the development team (of two) in handling the Project timeline, deliverables, management and communication through Slack channels & JIRA. Our usual product development procedure consists of:

• Daily & weekly syncs & stand ups
• Weekly planning & (if necessary) unblocking interventions
• Leadership team (CEO, CTO, CDO, Head of Biz-Dev) consulting on technology and management steering sessions

With that said, the complete team for this project would consist of:

• 2x Senior Solidity (Smart Contract) Developers
• 1x Project Lead
• Consulting from the Leadership team

Project Costing

The total amount being requested from our team is 71,250 EUR (+ Maintenance) which can be broke into payment upon each milestone delivery/deliverables shared:

• Milestone no. 1: (3 weeks): 11,250 EUR
• Milestone no. 2: (12 weeks): 45,000 EUR
• Milestone no. 3: (4 weeks): 15,000 EUR

plus:

• Milestone no.4 & 5 / Maintenance (recurring, estimated at around 4 months): 7,000 EUR / month

Contact Info

aleksandar.dimitrijevic@mvpworkshop.co

Team Website

https://mvpworkshop.co/

Relevant Experience

Our team has taken part of the FVM Early Builders program, building FileSaver, and has entered the grand finale (top 12 projects) amongst 250+ teams in the ETH Global hackathon organized earlier this year (February, 2023), also entering the spaceWarp accelerator program, working alongside dedicated PL mentors for future project improvements.

Team code repositories

https://github.com/MVPWorkshop, https://github.com/andrejrakic, https://github.com/schrink, https://github.com/bojinovic

[BlocksOnAChain]

@alexdimitrijevic - Hey Alex, thanks for sharing this.

I will review the proposal as one of the technical sponsors.

For us to have a complete overview, please share your costs to implement all the things you listed + the relevant GH profiles of the developers working on this project hands-on.

[alexdimitrijevic]

Hey @BlocksOnAChain ! Thanks for the comment. I've edited the issue with what you've suggested, and you can find both 'Project costing' and our development team's GitHub profiles in the content.

[BlocksOnAChain]

@alexdimitrijevic, we also miss your proposal and plans for future project maintenance after all the work on the RFP features is done. Can you add that to the main section, please?

[alexdimitrijevic]

@alexdimitrijevic, we also miss your proposal and plans for future project maintenance after all the work on the RFP features is done. Can you add that to the main section, please?

Hey @BlocksOnAChain ; I've updated the proposal with the Maintenance deliverables and timeline. Thank you for the feedback.

[BlocksOnAChain]

The thing we want to add, based on our meeting talks on 2022/06/20:

• We will add Phase 2 for the RFP that will address: Epic: Bytecode and gas reduction
• Test coverage - add testing and coverage plans to the RFP. We can do it as part of the maintenance epic
  We can start with Hardhat and expand to Foundry later.
  We would like to see that coverage report as part of the deliverables for this project.

CC: @alexdimitrijevic @scotthconner

[alexdimitrijevic]

Thanks @BlocksOnAChain

Looking forward to scoping additional requirements for the bytecode and gas reduction with the team

I'll add @andrejrakic, our Tech lead for the project so he can be updated with the changes, as well as confirm the corrections on the test coverage.

[alexdimitrijevic]

@BlocksOnAChain , @scotthconner , @andrejrakic

Re: based on internal MVP Workshop meeting on June-22, 2023:

I've edited the Proposal with the 'Milestone 5' information regarding facing 'Bytecode & Gas optimization' challenge according to the timeline.

[scotthconner]

Thanks for the additional revs on this RFP. I think we are ready to move forward here. Excited to see improvements!

[BlocksOnAChain]

@alexdimitrijevic - can you share more details on M4 and M5 and why is it binding for the mentioned period?
I'm assuming M4 is for maintenance of what we build, but I don't fully get M5; what deliverable will you provide to justify the cost for those eight weeks? I think we can leave it as part of M4 and try to do improvements when we are low on tasks for the maintenance side of things, so we can keep things under the budget restrictions that we have.
What do you think?

[alexdimitrijevic]

Hey @BlocksOnAChain: Thank you for the clarification! I agree that for now, M4 and M5 can be a part of the maintenance of the project, upon delivering M1-3 as the core project delivery timeline (help from both community and FEVM core team is definitely crucial here:)

The initial suggestion was due to the complexity of the assignment, which left us to assume the technical scope of M5, but with further discussion and clarification, we are ready to move on with a suggested format

[smagdali]

@alexdimitrijevic could you update the project costing to reflect that? thanks.

[BlocksOnAChain]

@smagdali from what I can see, the changes are done now. We can start working on the contract draft and kick-off development after that.

[BlocksOnAChain]

This RFP is now closed and the active work on it started, so we can close the RFP now.