Oct 08•4 min read
Photo credit : birgerstrahl
Let's talk about Clarity, the language that brings smart contracts to Bitcoin.
I will cover the design decisions behind Clarity, and some of the features of Clarity that makes it different from other smart contract languages.
Meet Clarity
Clarity is built by @hirosystems and @Algorand as part of the @Stacks ecosystem. It optimises for predictability and security. It is decidable, interpreted, predictable. It has FTs and NFTs embedded in it and has access to the burn chain. Lots of jargon. Let's dive in.
Clarity is a Lisp like programming language and the syntax is totally different from any language you may know. Lisp programs are trees of expressions of which each returns a value. It does not have operators but only functions. That makes it more consistent and easier to parse.
Clarity is decidable
What does that mean? To understand that, you first need to know what Turing Completeness is. A Turing Complete language can solve any of computation problem. Imagine that for some reason, a language cannot perform addition operation one way or the other.
That makes it a non Turing Complete language. Most of the programming languages today are Turing Complete. Clarity is intentionally designed not to be Turing Complete. There are simply some operations you are not able to do. For example, you cannot do a for-loop in Clarity. Also, you cannot do recursions.
What is the benefit of that? It avoids "Turing complexity". You cannot have an infinite loop in Clarity nor can you have recursions. No one wants to get stuck in an endless loop when every executed line costs real money. To do loop operations in Clarity you can use map/reduce operations that operate on fixed-length lists. And yes, lists in Clarity cannot have variable lengths (except for function inputs). You cannot append or join lists either.
Decidability removes a whole class of unintended bugs and issues that can happen where a codebase gets complex.
Clarity is an interpreted language.
This means the code is not compiled into bytecode or any intermediate (unlike Solidity with EVM bytecode). The contract code is directly published to the blockchain and can be read at any times. E.g. check PoX contract.
This is a huge benefit especially when large sums of capital need to be locked or transferred in the code. In case of Ethereum you cannot read the source code of 99% of the contracts unless it is published. After all, who wants to sign a contract without having read the terms.
Clarity does not permit reentrancy. Imagine contract A calls contract B and then B calls contract A again. This may allow an attacker to invoke multiple token withdrawals before the contract can update its state and drain the wallet. Clarity does not allowed this.
In Clarity, fungible and non-fungible tokens are supported right off the bat. There are builtin functionality to create the balance sheet, manage supply and perform token operations.
Clarity has access to the base chain.
Since @Stacks is settled on Bitcoin, that means you get direct access to Bitcoin chain from your contract. That is a great feature which allows building smart contracts that directly respond to Bitcoin.
An example of that is Catamaran Swaps (http://catamaranswaps.org) by @fmdroid where you can do a native Bitcoin swap and exchange BTC with digital assets on @Stacks .
I've tried to cover what I know about Clarity. Learning Clarity is a bit mind bending at the beginning due to syntax and new paradigms. I'm still learning Clarity at Clarity Universe by @MarvinJanssen and I'm soon going to publish a custom special NFT project as my warm-up.
I'm also planning to do in depth analysis of bigger projects such as @SyvitaGuild projects, @alexgoBtc or @ArkadikoFinance to learn more about Clarity development.
If you're interested and want to learn with me, you can follow me @codexbtc .
.
.