Contents
I joined Hiro in early 2020 as the Product Lead for Developer Experiences. During my first few weeks, I began researching and learning everything I could about the new Stacks 2.0 blockchain. Initially I was thrown off, but also intrigued, by some very particular engineering design decisions. Stacks was investigating novel and nuanced implementations of blockchain tech, and always had an inclination to zig when others zag. In addition, Stacks had the advantage of being a fast learner in the smart contract space when the new Stacks blockchain was designed. It was possible to absorb the learnings that unfolded in the Ethereum space during and after the ICO craze. And - there were plenty!
This post aims to highlight two seemingly little design decisions of the Stacks blockchain that have a big potential: Truly verifiable and usable smart contract sources. Let me explain…
The Passing of the Baton
With the rise of smart contracts, individuals no longer have to trust each other that a contractual obligation will be met. While that may be true, the trust has now shifted onto the developer of a smart contract. One could argue that passing the baton to an unfamiliar developer makes it even more difficult to ensure accountability. How many of us know and trust a developer of a smart contract we might want to interact with?
This challenge is nowadays mostly tackled in a few ways:
• Developers are open-sourcing the uncompiled sources of contracts. This is a great idea, but doesn’t guarantee that the contract being signed is based off this source version.
• Companies are auditing smart contracts and developers release the reports. This is a very valuable solution, but in similar ways passes the baton to another entity that we have to trust.
• Blockchain explorers enable developers to upload the sources for deployed contract manually. The explorer would collect some information and verify it against the byte-code of a contract on the network. This is a great solution, but relies on manual work and explorer support.
To alleviate some of these transparency pain points, Stacks did two things differently: First, it decided to use a non-compiled smart contracting language, Clarity. Second, it made it mandatory to publicize the source of each contract. As a result, every smart contract deployed on the Stacks network includes the executable, uncompiled, and human-readable source.
This is a very important outcome: Individuals do not have to trust other entities! They can verify and trust the deployed contract itself.
Now, how do these design decisions affects developers? In short, it enables the “GitHub of smart contracts”.
A Smart Contract Flywheel
In the current stage of the blockchain space, smart contract developers have a particularly difficult task. Oftentimes, they have to learn new languages (or flavors thereof), working sample code is hard to locate, and there’s frequently a new way of doing things or best practices being standardized.
The most successful smart contracting platforms do their best to collect great sample projects, annotate and comment code pieces, and make them more discoverable. OpenZepplin Contracts is a fantastic example of such a collection. The difficulties with solutions like this are pretty well-understood: They either have to be maintained constantly or will start to create negative effects (outdated sample code is frustrating).
Thanks to the aforementioned design decisions, the Stacks network excels in this area. Thanks to the of the availability of executable, uncompiled, human-readable sources for any smart contract deployed on the Stacks blockchain, developers get access to always up-to-date, functional smart contracts. Websites such as GitHub can make it easy for developers to discover relevant code samples, learn from other developers’ code, and kickstart their own projects.
I think over the course of the next years we will see the Stacks smart contract flywheel taking off:
Availability of working contracts will attract developers. Developers will be able to build off of existing smart contracts, making even more contracts available for even more developers.
The best part of all of this: It is not a vision for the future! We don’t have to wait much longer, and the discoverability of Clarity contracts is already being utilized. Head over to the tool, Clarity Search, to find over 70+ working smart contracts deployed to the Stacks mainnet and start building your own smart contract on Bitcoin! This new smart contract archive pulls data directly from the blockchain, and displays an organized list sorted by recently deployed. No longer will you have to comb through the Explorer to locate a particular contract. Clarity Search is a powerful search engine that lets you select certain parameters and and filters. It also displays interesting metrics like the number of contract calls a file performs, or the overall complexity of the code. This will be absolutely integral for quickly browsing the network for functional smart contracts already in production.
Good luck on your smart contract safari, developers!
