Modular Libraries is a group of packages built for use on blockchains utilizing the Ethereum Virtual Machine (EVM). All libraries are deployed and linkable in your smart contracts on both Rinkeby, Ropsten, and Ethereum Mainnet. We also have an ethereum-contracts repository that currently holds ICO contracts.
Libraries and contracts are currently written in Solidity and Solidity Assembly. If you are not familiar with the workings of Ethereum, smart contracts, or Solidity please educate yourself by clicking here before proceeding.
If you want to contribute to the libraries or just join the discussion on smart contract development and security, please join our Discord at https://discordapp.com/invite/crxYSF2
- Why Modular Libraries?
- How to use
- How to Contribute
- Why Libraries?
- In Conclusion
Why Modular Libraries?
Modular Libraries aims to supplement current projects such as Open-Zeppelin and others by utilizing the facilities Ethereum has in place to provide reusable source code on-chain. Our library code has been tested, documented, and deployed with the purpose of being used in Ethereum smart contracts. Be sure to familiarize yourself with libraries as well as the benefits and drawbacks to ensure you pick solutions that best fits your needs.
While we make every effort to write, review, secure, test, and document professional grade code, all code is released open source under the MIT license and "without warranty of any kind." We shall not be held liable for any damages or lost funds so please be careful and prudent with your implementation. Please review and familiarize yourself with the entire license and accompanying disclaimers.
How to use
Modular Libraries has been packaged such that each library is available independently from any other library. You can browse each folder and pick the library or libraries that you need for your smart contracts.
The README in each library contains the Rinkeby, Ropsten, and Mainnet address of the deployed library to link in your contract. You will find documentation for the functions and installation instructions for development and deployment use as well. Additionally, each library has as an ENS domain which is not of much use now but will provide a better experience as development proceeds. All deployed source code has been verified on etherscan.io for your viewing pleasure.
How to Monitor Events Emmitted by Modular Libraries
In docs/LibraryLogHashes.csv, you can find a listing of all of the zero-topic hashes for the events that our libraries emit. You can use these in your web app to monitor events that contracts that use our libraries emit.
How to Contribute
Feedback, bug reports, library submissions, collaborations, and contributions are all welcome! We will be rewarding contributions so please do not hesitate to reach out to us.
Feedback and Bug Reports
If you have feedback about our libraries or questions about our documentation, or find a bug in our code, please contact us as soon as possible at email@example.com or reach out to us on on Gitter or Discord channel. Significant contributions will be rewarded.
As part of the global Ethereum/Blockchain community, we at Modular want to do our part in supporting fellow projects and enthusiasts in the community. If you need an audit, advice, help building a secure ICO or Ethereum Dapp, or any other type of collaboration, please get in touch at firstname.lastname@example.org where we can discuss the collaboration.
If you see an issue in our repo or a piece of code in our Libraries you want to improve, please don't hesitate to dive in. We welcome help in any form and are more than willing to offer our assistance to developers who want to contribute to documentation, code fixes, or even new libraries or functionality! We ask that you follow a few guidelines when making changes to the repo:
- Create a branch separate from master for any changes.
- Create separate branches and submissions for unrelated changes.
- Please adhere to Ethereum Natural Specification Format Guidelines for function documentation. Also, leave comments on functional blocks in the code so that any functionality is easy to understand by any moderately competent developer reading the code.
- If you are making significant changes, include a README with function signatures, inputs, outputs, and a detailed description of the functionality.
- Include the description of the changes on the Pull Request.
- When creating a pull request on the main repo, do not submit it to master. Either submit it to an existing branch that was allocated for the changes, or submit it to a new branch you create with the PR.
We strive to maintain high standards at Modular. To accomplish this, we have included unit tests and a coverage report tool. We are using the solitidy-coverage tool and Codecov to host our reports and analysis. Let's keep growing our coverage percentage as much as we can!
Utilizing libraries has some of the following benefits:
Reduce deployment costs
The overall bytecode load you deploy for your own contracts is reduced because your contract will not contain the function used from a linked library's external function. Your contract will make external calls to a linked library.
Common libraries and reusable source code naturally receive higher visibility and scrutiny. This provides better code for developers as well as a known location to report and review bugs after many use cases.
Libraries help to improve the security of your code because of the same circumstances that provide reliability. With that said please review the license and disclaimer before use.
Utilizing libraries has some of the following drawbacks:
Increase execution costs
Using external calls to library functions on-chain causes some overhead that does not exist when using internal functions. So, while contract deployments are less expensive, contract gas usage increases with execution. If this is a concern and you have a higher need to reduce gas usage upon execution than to reduce gas usage upon deployment, you can modify the contract function with an internal modifier. This will pull the function into your contract when you deploy. Please review the Solidity docs on libraries if you are not familiar with this.
Deployed libraries are immutable
This is a concern more for our approach rather than the approach other repositories use. Since our focus is on deployed libraries, the code at this address is as permanent as the blockchain. Don't hold your breath for changes. There are some upsides in that immutable code is guaranteed to never have a breaking change so you can rely on it for as long as it is relevant. There are initiatives we've seen, particularly with Aragon and OpenZepplein, that plan on making library code upgradable to a certain extent. We will keep an eye on these developments as well as continue our plans to help develop a versioning system on-chain.
Understanding someone else's code
For the same reason libraries give us the benefit of reusable community code, it requires us to understand someone else's logic. Again, we strive for excellence, but sometimes it may not be the best implementation. Such as when we have used Solidity Assembly to improve our own competence in the language, the same thing could be done just as efficiently in basic Solidity. Our approach to this downside is to ensure we verify the deployed code and provide adequate documentation.
As always you should stay informed and determine what works best for you and your project. We look forward to working with everyone and we welcome anyone that wants to collaborate. [Please visit modular.network](https://modular.network"Modular website") to see more information about us and opportunities.