Merge pull request #3 from violetprotocol/dev

1.0.0

Author: 0xpApaSmURf

.env.example

@@ -0,0 +1,6 @@
+REPORT_GAS=
+PRIVATE_KEY=
+RINKEBY_NODE_URL=
+KOVAN_NODE_URL=
+TENDERLY_USERNAME=
+TENDERLY_PROJECT_NAME=

.gitignore

@@ -0,0 +1,14 @@
+node_modules
+.DS_Store
+.env
+
+#Hardhat files
+cache
+artifacts
+
+#Release build
+contracts/build
+contracts/README.md
+build
+
+coverage*

.prettierignore

@@ -0,0 +1,21 @@
+# directories
+.yarn/
+**/.coverage_artifacts
+**/.coverage_cache
+**/.coverage_contracts
+**/artifacts
+**/build
+**/cache
+**/coverage
+**/dist
+**/node_modules
+**/types
+
+# files
+*.env
+*.log
+.pnp.*
+coverage.json
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*

.solhint.json

@@ -0,0 +1,10 @@
+{
+  "extends": "solhint:recommended",
+  "plugins": ["prettier"],
+  "rules": {
+    "compiler-version": ["error", "^0.8.0"],
+    "no-inline-assembly": "off",
+    "avoid-low-level-calls": "off",
+    "no-empty-blocks": "off"
+  }
+}

.solhintignore

@@ -0,0 +1,3 @@
+# directories
+**/artifacts
+**/node_modules

README.md

@@ -1 +1,103 @@
+# Extendable Contract Pattern
 
+Upgradeable, modular, extensible smart contracts using Extendable<>Extension architecture.
+
+Add and remove selectively modular parts of functional logic known as Extensions, accessing modular storage definitions.
+
+```solidity
+contract YourContract is Extendable {
+    ...
+}
+```
+
+```
+> deploy(YourContract)
+> YourContract.extend(extension);
+```
+
+## Architecture
+
+Contracts are given their functionality by _extending_ them with new functions. The first function that is added is the _Extend_ function which provides the contract the ability to be extended.
+
+### Extendable
+
+All contracts must inherit the _Extendable_ contract.
+
+_Extendable_ contracts have a unique interaction with the _ExtendLogic_ contract where Extensions are added. _Extendable_ contracts access the state written by the _ExtendLogic_ extension in order to perform delegate calls to each extension. All calls are done from the context of the _Extendable_ contract which is handled by `delegatecall`.
+
+_Extendable_ contracts have an evolving interface which is accessible through the `getCurrentInterface` function supplied by the _ExtendLogic_ extension. This allows developers to easily determine the current interface of an evolving _Extendable_ contract directly on-chain without having to query separate processes that may not be in sync (GitHub, Documentation, Twitter etc.).
+
+### Extensions
+
+_Extension_ logic contracts implement functional logic that is called by the _Extendable_ contract. Following extension principles of modularity and updateability, it is recommended to separate logic contracts into the most divisible units possible: single function contracts. Where logic contracts encompass more than a single function for dependency or cohesive reasons, it can envelope more functions but with the trade-off of being less modular; any upgrades to a single function require the entire logic extension to be updated and re-registered.
+
+_Extension_ logic contracts can mutate state by accessing the storage of the delegator through custom storage slot access. Various different _Extension_ logic contracts can access the same state but extensions should be written and extended mindfully to avoid incorrect state mutability.
+
+```solidity
+import "@violetprotocol/extendable/extensions/Extension.sol";
+
+contract YourExtension is IYourExtension, Extension {
+    ...
+}
+```
+
+```
+> deploy(YourExtension)
+0x7F5b1b0a4929BF2bD9502CBF714c166931FC85dD
+> YourContract.extend(0x7F5b1b0a4929BF2bD9502CBF714c166931FC85dD)
+```
+
+### Storage
+
+_Storage_ contracts define state variables that intend to be stored and used by an _Extendable_ contract and accessed by _Extension_ logic contracts. It uses a storage slot locator model where storage is allocated and accessed by address and different structures/types are located in different places to avoid collision.
+
+_Storage_ contracts are libraries that are imported by the contract that requires access to storage state. These contracts can include reusable functions that might be useful related to computation over state (such as modifiers or _get_ functions).
+
+```solidity
+struct YourState {
+    // State variables are declared here
+}
+
+library YourStorage {
+    bytes32 constant private STORAGE_NAME = keccak256("your_unique_storage_identifier");
+
+    function _getStorage()
+        internal 
+        view
+        returns (YourState storage state) 
+    {
+        bytes32 position = keccak256(abi.encodePacked(address(this), STORAGE_NAME));
+        assembly {
+            state.slot := position
+        }
+    }
+}
+```
+
+```solidity
+import "@violetprotocol/extendable/extensions/Extension.sol";
+import "./YourStorage.sol";
+
+contract YourExtension is IYourExtension, Extension {
+    function readStorage() public view {
+        YourState storage state = YourStorage._getStorage();
+
+        // access properties of state with `state.yourVar`
+        // re-assign state properties with `state.yourVar = <value>`
+    }
+}
+```
+
+## Requirements
+
+`nodejs >=12.0`
+
+## Build
+
+`yarn install` to install all dependencies.
+
+`yarn hardhat compile` to build all contract artifacts.
+
+## Test
+
+`yarn hardhat test` to run tests.

RELEASING.md

@@ -0,0 +1,53 @@
+# Releasing
+
+To cut a new release, first create a pull request from `dev` into `main` with the [semver](https://semver.org/) naming convention. For example `1.0.0-rc1`. This will enter wider team review and further testing where necessary to ensure bug-free code and presentableness to public.
+
+## Testing
+
+Run tests and coverage:
+```bash
+$ yarn test
+$ yarn coverage
+```
+
+Manual testing using hardhat tasks and public testnets are encouraged.
+
+Mock development by using the library is also encouraged (or the use of bug bounties).
+
+## Preparing for NPM
+
+Enter the contracts directory:
+
+```bash
+$ cd contracts
+```
+
+Test the npm package with:
+```bash
+$ yarn pack
+```
+Ensure the resulting tarball includes all files that you expect the package to have.
+
+Then create a new folder with a test project and install your package:
+```bash
+$ mkdir test-project
+$ cd test-project
+$ npm init
+$ npm install <path/to/contractsdir>
+```
+The package should now be installed in your project's `node_modules` and the contracts should be accessible through imports `import "@violetprotocol/extendable/extendable/Extendable.sol";`
+
+## Merge and Release
+
+Once checks and reviews pass, the release can be merged to `main` and then tagged with the normal release number without the release candidate tagging e.g. `1.0.0`.
+
+Then perform the publishing step to npm:
+
+```bash
+$ cd contracts
+$ yarn prepare
+$ npm login --scope=@violetprotocol
+$ npm publish --access public --tag <version>
+```
+
+Ensure that the tag includes a changelog that documents the feature changes/additions/fixes that were included in the version that diff from the previous release.

contracts/errors/Errors.sol

@@ -0,0 +1,27 @@
+//SPDX-License-Identifier: MIT
+pragma solidity ^0.8.4;
+
+/**
+ * @dev  ExtensionNotImplemented error is emitted by Extendable and Extensions
+ *       where no implementation for a specified function signature exists
+ *       in the contract
+*/
+error ExtensionNotImplemented();
+
+
+/**
+ * @dev  Utility library for contracts to catch custom errors
+ *       Pass in a return `result` from a call, and the selector for your error message
+ *       and the `catchCustomError` function will return `true` if the error was found
+ *       or `false` otherwise
+*/
+library Errors {
+    function catchCustomError(bytes memory result, bytes4 errorSelector) internal pure returns(bool) {
+        bytes4 caught;
+        assembly {
+            caught := mload(add(result, 0x20))
+        }
+
+        return caught == errorSelector;
+    }
+}