Violet is a tool chain to compose, express, and verify identity on-chain. Web3 broadly has created a unique opportunity for greater inclusion of use-cases that have identity at its core. For us, global participation and widespread adoption comes with a need for a fairer and more transparent construction for identity - one where agency is placed back into the hands of the user.
While we are most excited about catalyzing institutional participation across DeFi in the near term (to help the space grow and become more robust), we believe Violet will serve as a primitive for many use cases.
Generalizable and composable on-chain credentials are a key design pattern in our system which we use to prove characteristics or behaviours about individuals while preserving their privacy. However in order to support reusability and custom logic on-chain for a wide range of different credentials we have built a new framework we want to share here.
Enter the Extendable Framework
The Extendable Framework is a novel smart contract development pattern to allow dynamic and modular runtime extensible contracts that are upgradeable, reusable and composable. Builders can flexibly add or remove functions from your contract, update existing logic and extend your smart contract interface to support a growing set of use-cases.
Like the commonly used Proxy pattern refined and popularized by OpenZeppelin, upgradeability is a core tenet to the pattern. In the Proxy pattern, a contract consists of two components, a Proxy which acts as the facade and entry point for transactions, and an implementation, which sits behind the Proxy but contains all the functionality and logic.
We’ve built on top of innovations like this to improve the way that upgradeability can be performed by separating the contract into more discrete component contracts where each section of a contract can be independently modified and updated without upgrading the entire thing.
The Diamond Standard provides a similarly great approach to smart contract upgradeability and is also another key inspiration for our work here. We wanted to create a framework that could be as easy to implement as regular smart contracts that leaned heavily into reusability, modularity and flexibility, without introducing any additional difficulty in use or development alongside the added complexity.
With that in mind, the Extendable Framework was born. Let’s take a deeper look at how we achieve this.
Let’s dive in
The Extendable smart contract pattern allows your contract to be extendable with smart contracts called Extensions that can be selectively added and removed from your contract. But how does it work and how can you make use of this pattern?
To make your contract Extendable, simply inherit the Extendable.sol contract:
`contract YourContract is Extendable {}`
This provides your contract with all the functionality to allow it to be extended. Your contract then becomes a collection of extensions as modular functional units instead of your usual monolithic contract codebase.
Instead of writing functions for your contract you can now write Extension modules that can be reused across many different contracts. Extensions can be replaced in the case of upgrades, removed in the case of deprecation, and added where new functionality is needed. There are also many more ways to use extensions depending on your needs. Each extension can read and write state as normal through a different state storage access pattern.
State variables are defined inside separate modules called Storage Modules. These are library contracts that provide access to any state variable that you define. However instead of declaring and defining them as regular storage variables in your smart contract, they are declared as structs that your Storage Module will reference to whenever you need to read from or write to it.
The separation of layers between logic and storage means that you can write any kind of functional logic to be able to access state variables as usual but with the powerful flexibility afforded by your contracts being extendable.
This means that deploying similar contracts like tokens will be much cheaper as you can simply re-use common token logic such as ERC721 or ERC1238, instead of having to redeploy the exact same code. Your contracts will have static addresses so upgrades to logic won’t break any integrations, similar to common Proxy patterns, and upgrades can be performed to small or large parts of your contract code through selective extension replacement.
Get involved!
The Extendable Smart Contract pattern provides a design approach for smart contract development and maintenance that solves many of the problems in smart contracts and enhances many of the benefits. By making your contracts Extendable you can build fully flexible, dynamic contracts that are robust and future-proof with maximal control over runtime functionality. Start building with the Extendable pattern:
Note that this is early work so we’d love to hear feedback and welcome contributions to the framework. We’re open sourcing our reference implementation early so we can continue the build, develop and iteration of this approach with the community in hand. We think smart contract design patterns are paramount in supporting the evolving complexity in decentralised applications but also importantly keeping the community safe through vetted and standardised patterns.
Stay tuned for a future post on implementation, as well as many ideas for improvements we are looking forward to sharing with you all soon.