filecoin-project / devgrants

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

RFP Application - Filecoin Solidity Optimization #1578

Closed hgergov closed 1 year ago

hgergov commented 1 year ago

RFP Proposal:

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: hgergov

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

The objective of this proposal is to outline the necessary additional work required to enhance and optimize our filecoin-solidity libraries, while also establishing ongoing maintenance and open-source stewardship for the betterment of the community. Specifically, our goals include enabling optimizability, aligning the libraries with the user-friendly features found in popular Solidity libraries such as OpenZeppelin, and minimizing the libraries' overall footprint. This includes the following epics:

Furthermore, there’s an active backlog of smaller issues that need to be fixed as part of continued maintenance. By implementing these improvements, we intend to enhance the usability and performance of our filecoin-solidity libraries, contributing to the overall development and adoption of the Filecoin ecosystem.

Development Roadmap

Backlog items implementation

Epic Description Effort (man-weeks)
Initial analysis, discovery, implementation of the findings Setup
- Conduct a comprehensive review of the current implementation, including code structure, architecture, and documentation
- Identify any potential areas of improvement or technical debt that may hinder future development
- Provide recommendations for improvement, prioritizing areas that require immediate attention
- Capacity for implementing the identified findings and improvements.
9
Compatibility with compiler optimizers (issue 295) A possible solution to the issues is to replace the msize opcode with mload and manually add the 32 bytes word that it is always the extension.
- identify all places where msize is being used in the solidity-BigNumber library
- replace with working solution the msize with another opcode and additions
- test whether everything is working properly; test if the solution is compatible with the optimizers and especially the Yul one.
5
Implementing backlog items For the sake of speed and not to reinvent the wheel the first solution would be to review in depth the solution described in the github issue below. If the solution works as expected and there are no regressions we will apply it to all places.
- Enable read-only “view” methods for protocol accessors ( issue 120)
- replace delegateCall , where possible in order to allow the usage of view functions
- https://github.com/wadealexc/fevmate/blob/main/contracts/utils/CallNative.sol#L53 - verify that the solution is working and apply it

During the Discovery phase and this issue investigation, we will identify places where the codes are not returned properly. Instead of reverting the transaction at those places, we would process the exit codes and return them to the users, thus providing them with proper way of handling the code.
- Propagate exit codes (issue 363) - currently exit codes are not displayed and returned. We need to make them visible.

Reverse the logic in order to get the eth Address
- Add toEthAddress functionality in FilAddresses.sol util ( issue 342)- research how the FillAddresses is actually working and how is generated based on the ethAddress

Currently there are some structure for common types available. While reviewing the code and the issue we would mark potential candidates would be useful for the users. Once we have them we would create structures that can be easily used after that.
- constructors for types (issue 31)
- investigate which other types would be useful for the users to have
- add more structures for creating the custom typesRefactor project structure (issue 116)
- refactor the repository file structure
- make the repo more readable
- make sure everything is working after the refactoring
9
Developer ergonomics While developing the other Epics and going through the issues, we will mark code and ergonomics improvements to the code. In a previous issue some of the structure objects would be created, we will go through the suggested improvements in the RFP, and find other places besides the mentioned ones where we could apply the methods. We will also improve the developer solidity documentation for the code, making it more useful and easy to understand
1. Reuse open zepplin helper methods where possible, instead of copy-pasting code in the contracts
- For example revise the Misc.sol contract and identify what can be made simpler. getPrefixSize and abs calculations can be improved.
2. Some methods can be improved and simplified like the calculations of cbor . This together with some comments can improve the gas. ( Use built in abi encoding where possible)
3. Remove and replace structures where possible
4. Libraries are used as namespaces, could we use something else like grouping by files
5. Mock the actors for testing purposes.
- deploy custom actors on testnet
- build local lotus nodes
8
Bytecode and gas reduction even though some of the reduction will be done with the optimiserz and other changes, investigate and identify hotspots and places for code improvements 3
Improving testing We will run code coverage tools to identify what parts of the code are covered with tests. In order to make the testing faster we will introduce unit testing and fuzz testing where applicable. 
- introduce solidity unit testing for simplicity and speed
4
    Total: 38 weeks

Team setup

  • 2x Full-time Solidity Engineers
  • Part-time Blockchain Architect
  • Part-time Project Manager
  • Part-time Tech Team Lead

FTEs: 2.5 Duration: 16 weeks

Maintenance and Support

Epic: Network upgrade evolution, OSS stewardship/maintenance

Team Setup

  • Full-time Solidity Engineers

FTEs: 1 Duration: 9 weeks

Development Process

  • Foundry will be used for smart contract development/testing and deployment and overall improvements of the library
  • Aiming for smart contracts to be delivered with at least 95% unit test coverage
  • Fuzz tests are to be implemented testing the described invariants in the spec file
  • Static analysis tools such as Slither will be used for analyzing the implementation
  • A CI/CD pipeline will be adapted for running compilation unit tests on every PR, together with publishing new versions of the library
  • At the end of the development, if desired, an internal audit may be performed by other top smart contract developers in LimeChain that have not worked on the project to get additional security guarantees
  • If an external audit is scheduled, LimeChain’s team will assist, be available for questions and resolve the comments from the produced audit

Milestone Summary

Milestone No. Milestone Summary & Staffing Funding Estimated Timeframe
1 - Initial analysis, discovery, implementation of the findings
- Compatibility with compiler optimizers (issue 295)
€47600 6 weeks
2 - Implementing backlog items
- Developer ergonomics
€57800 7 weeks
3 - Bytecode and gas reduction
- Improving testing
€23800 3 weeks
4 Epic: Network upgrade evolution, OSS stewardship/maintenance €13600 4 weeks
5 Epic: Network upgrade evolution, OSS stewardship/maintenance €17000 5 weeks

Total Budget Requested

€159800

Maintenance and Upgrade Plans

LimeChain commits to supporting the library until the end of the year as active code owners. Our aim is to continually cycle changes and refine the library, and in doing so, maintain a contextual experience. Thus ensuring the library's ongoing success and effectiveness.

Team

Contact Info

hristo.gergov@limechain.tech dimitar.ivanova@limechain.tech

Team Members

Team Website

https://limechain.tech/

Relevant Experience

LimeChain is a blockchain development and consulting company, building dApps and infra/networks since 2017. Our experience building blockchain solutions has led us to two core beliefs: that results speak for themselves and that blockchain will be the revolutionary technology in the decades to come. We are driven by that philosophy to help pioneer the development of blockchain, one of the most groundbreaking technologies to develop this century. LimeChain is united by those two passions, belief in the power of results and the power of blockchain.

In terms of dApps - we have built DeFi, NFT and Metaverse apps including bridges (Alliance Bridge, Hashport), DeFi apps (MANTRA Finance, FIAT DAO, Altitude, Alliance Block), NFT marketplaces and apps (Universe, NFT Embed, Ledger Market, LeagueDAO), Metaverse land renting platforms (LandWorks), gaming platforms (MetaPortal).

In terms of infra - we've built development tooling for Optimism, The Graph, Filecoin, Polkadot and Hedera. In terms of L1s, LimeChain is the core development team at Hedera.

Within the FileCoin ecosystem, our is currently finalizing the Solidity implementation for the IPC Subnet and Gateway Actors.

Team code repositories

https://github.com/LimeChain

Additional Information

Upon approval, we intend to leverage the existing team setup, which is presently in the final stages of completing the Solidity implementation for the IPC Subnet and Gateway Actors.

hgergov commented 1 year ago

Hey @scotthconner @BlocksOnAChain

After some additional research, we have included additional descriptions outlining our approach and provided an updated estimate of the effort required. We have also made updates to the Maintenance and Support (Epic: Network upgrade evolution, OSS stewardship/maintenance) phase, as its required effort and duration will be reduced due to the increased duration of time towards the other milestones.

BlocksOnAChain commented 1 year ago

@hgergov Thanks for sharing all the details and working on the proposal.

As mentioned on Slack, after careful consideration, we decided that we are going to hire a different team to help us build all the backlog items and improvements we listed in the RFP. Hopefully, we can work together on the next one. 👍 Thanks for your time and hard work on the proposal.

CC: @scotthconner @ErinOCon for visibility.