Contents
The Humble Beginning of Clarinet
Clarinet started from a personal frustration. In the spring of 2021, I was trying to use Clarity for writing a protocol that would let me move some BTC back and forth between Stacks and Bitcoin, and I grew frustrated at all of the time required for testing my Clarity contracts.
I had some experience working with tooling from other blockchains, and I saw the opportunity of creating something new for Clarity, based on those experiences with different ecosystems and different technological stacks.
The first proof of concept of Clarinet that I released for my eyes only had one feature: clarinet console - the ability to initialize a REPL with a few contracts, loaded in the right order. It was a simple idea, but yet, it turned a 2 minute task involving a succession of 5 commands into a 1 command / few millisecond process. This focus on productivity was already a big upgrade.
I then added the ability for developers to drive a Clarity VM/REPL with JavaScript code for designing a test harnessing system. This focus was meant to help developers build confidence in their work.
This product seemed valuable enough to gauge interest from developers, so we socialized the first versions of Clarinet about 1 year ago. After a few internal discussions at Hiro in early Q3 2021, we concluded that the early feedback was promising and that we should push the product further.
Learn more about the origins of Clarinet in a conversation with the Clarinet development team:
The State of Clarinet Today
If you want to satisfy developers, here’s a good repeatable recipe to follow: focus on features that bring more productivity and confidence to their work.
In the development of Clarinet, we spend a lot of time meeting with developers who use the tool. We work to identify the productivity and confidence pitfalls in the tool as it exists today, and we use our intuition to build features that address them.
Over the last year, Clarinet has been used for solving many pain points for developers, including (but not limited to):
- Ability to measure code coverage
- Ability to test contracts on an actual blockchain
- Ability to write integration tests
- Ability to debug Clarity code step by step, from console and VS Code (inline debugger)
- Ability to create cost estimate reports (cost estimator)
- Ability to detect contract flaws via static analysis (check-checker)
- Ability to build protocols on top of each other, using contracts already deployed on Mainnet
Clarinet was an experimental project during its first few months, and during that time a good amount of technical debt was accumulated (mostly because of shortcuts taken for the sake of shipping something to developers).
A few months after publishing the first public releases of Clarinet, Brice joined the Hiro team, and together we started approaching old features with a new level of diligence: if things work, great, but if they don’t, we made the difficult decision of doing an architecture reboot—no compromise.
Some examples of that work include:
- The Clarity Parser was too esoteric in terms of the errors being reported. We rebuilt the feature, and the new refactoring was so good (8x faster) that it actually ended up being merged in the stacks-blockchain, and will become the default parser in the next versions of the Stacks blockchain!
- The test harnessing system inefficiently consumed memory. We rewrote the system and made it 2 to 3X faster than the previous iteration.
- The contract dependency management previously forced developers to manually list their dependencies exhaustively. That management is now completely abstracted.
- Contract deployment lacked modularity and blocking requirements. With recent versions, Clarinet can now be used for reproducible deployments.
Developers seems to enjoy the productivity boost that comes from working with Clarinet, and it seems reasonable to state that Clarinet, today, can be of great help to developers, from their first contracts to deployments to everything in between (which includes manual tests, debugging contracts, unit test, integration tests, cost optimizations assistance, and smart contract integration assistance).
The Future
When looking at the future of Clarinet, it seems important to use 2 lenses:
Future of Clarinet
We think that Clarinet is feature complete for v1.0. The last item on our checklist before an official v1.0 consists in switching from a fork of the Clarity VM, to the canonical Clarity VM. This re-wiring is non trivial and will probably require a few pull requests, as well as back and forth with the stacks-blockchain repo. We need to make sure that the clarity-vm in this repo can be used as a library that can be used independently of the MARF, and in a WASM context.
Completing this effort will have some great side effects: developers will have some tooling to work with future versions of Stacks, and developers can have a guarantee that the latest version of Clarinet is always relying on the latest version of the Clarity VM. This will also be beneficial for the stacks-blockchain because as developers, we will have a way to test next features and spot eventual bugs / required adjustments ahead of time.
Clarinet’s current feature set is quite rich, and understated. Before adding more features into the mix, we want to focus on ensuring that developers who use Clarinet fully understand and leverage all of these features. In the future, we may further refine features, adding more optionality and flexibility for developers.
Clarinet structures Clarity development in an opinionated fashion. We make a few decisions for developers and design a flow to help them navigate their smart contract development. Alongside that flow, we’ve also embedded some components that have nothing to do with that opinionated flow. Such features include implementations for LSP (Language Server Protocol), DAP (Debug Adapter Protocol) and a Jupiter kernel. We have some other projects in this vein, like a Clarity linter, or contract documentation engine (a la Doxygen).
Additionally, contract testing is an area where a breakthrough (a new way of writing tests), leveraging Clarity decidability, could be done. We’re not planning to work on this, but we’d be happy to support any effort here. We also want to make sure that Clarinet is open and flexible enough to support tight integrations with tooling from other developers.
Lastly, we plan to keep supporting and pushing on cross chain features. Our anchor is in Stacks, but both Bitcoin and Hyperchains should be first class citizens. We will keep working on pushing integration with these 2 systems.
Thinking Beyond Clarinet
In Q1 2022, we spent a few months researching what could be the next steps for Clarinet. This research ended in some interesting prototypes, but it also revealed that some parts of Clarinet had to be rewritten and pushed further, which was the focus of Q2 with the introduction of deployment plans and chainhooks. Read more about those features here.
With those improvements aside, Clarinet is taking an interesting future direction: it is in the process of being deconstructed into reusable components.
The Clarinet team’s mission is all about helping developers diving into Clarity with productivity and confidence. Today, Clarinet, as a command line tool, is designed to help developers from their first contracts, to contract deployments. If we look at a typical developer journey, there is a life before contract #1, and there is a life after contract deployments.
Some components of Clarinet can be assembled, in different ways, for creating these other products - but discussing both is out of scope for this blog post :) .
Conclusion
Clarinet wouldn’t be where it is today without input and support from our community. Thank you to the developers that use Clarinet, thank you to the developers who have given us feedback, and thank you to the developers who have contributed to the project on GitHub. If there are things you would like to see on the Clarinet roadmap, chat with us on the #clarinet channel on Discord or open an issue on GitHub.
