It’s straightforward for you to communicate with your parents in a native language. Right? If you don’t know Russian, then you can not communicate with a person who understands Russian only.
Language is a crucial component for any communication process, and that’s why new emerging Blockchains come with their own smart contract languages. Blockchain specific smart contract language enables smart contracts to interact and utilize their blockchain to its full extent.
The most popular blockchain for smart contracts is Ethereum and its widely used smart contract language — Solidity.
With their recent announcement, Facebook introduced a new Blockchain — Libra, and its smart contract language — Move.
Blockstack, a decentralized computing network and app ecosystem that puts users in control of their identity and data, introduced Clarity. It is the smart contract language for their Stacks V2 blockchain (currently under development along with Clarity).
With increased Blockchain adoption, we will see the emergence of more of these new blockchains along with their smart contract languages.
There are lots of battle-tested dApps (decentralized apps) running on Ethereum blockchain using solidity. The ecosystem has witnessed DAO hack, Parity Multi-sig bug, and reentrancy attack, etc.
The new smart contract languages claim to offer more security and imminent execution of the code.
In theory, Move and Clarity provide more safety, but a wise person once said:
The well-coded contract never fails.
Both Move and Clarity is still not as mature as Solidity and needs improvement. Also, they are yet to be tested for any production use.
Solidity
Solidity is a statically typed, compiled language with support for primary types like address, booleans, byte arrays, strings integers, enums, etc. and complex types like fixed-size & dynamic-size arrays, structs, mappings.
With struct developers, a developer can create their own named types so that others can reuse these custom types and helper functions if they are defined in libraries, or by inheritance, if they are defined in a contract.
Move
Move is typed and currently supports a small number of native types, but Move is very modular, via separate custom type definitions (unrestricted structs or resources) and static functions from actual data, stored in each account. Modules are state-less; it only contains code. Modules can define resource types (similar to Solidity structs) and functions. Move has first-class Resource type. A resource can never be copied, only moved. These guarantees are enforced statically by the Move VM.
Clarity
Clarity is an interpreted and Turing incomplete smart contract language as it tries to remove “Turing complexity.” This decision allows a complete static analysis of the entire call graph for a given smart contract.
Further Clarity’s support for types and type checker can eliminate unintended casts, Re-entrance bugs, and reads of uninitialized values.
A Clarity smart contract code can be analyzed for runtime cost and data usage, allowing predictive execution of code.
As Clarity doesn’t need bytecode representation (e.g., EVM bytecode for Solidity and Move bytecode for Move), it minimizes the surface area for introducing bugs. Bugs introduced by a Compiler is not an issue here.
We have gone through the similarities and differences of these languages, but it’s time for us to implement a similar contract in Clarity and Move. For an ERC-20 example Solidity code, you can checkout SpringRole’s SpringToken smart contract.
Clarity Implementation
We will define a map (like mapping in Solidity) name balances which map the address of the owner type principal to the available balance.
To define a map we use keyword define-map. Similarly, we will define another map for allowances (note that it is a map to another map).
To keep track of total supply we will define a variable name total-supply of type int using keyword define-data-var and assigned it a value of 0.
Now to fetch the user’s balance we will define function balance-of using keyword define. This function will take input account of type principal and return the balance from the map balances using keyword fetch-entry. Similarly, we can define a function to fetch the allowance given to a spender by an owner.
Note: Using define keyword will define a private function if you want a public function, then use a define-public keyword instead.
Now for the transfer function, we will define a private function transfer! which takes three input sender, receiver and the amount. As this function is modifying the blockchain by changing the balances, we put an exclamation mark (!) after the function name to indicate the same.
Now time to implement increase and decrease allowance function.
These two functions will be reused in the other function approve and transfer-from.
You can grab full implementation of contracts in Clarity from here.
Move Implementation
We will take advantage of Move’s Resource type to define different roles. (i.e. Minter, Owner, etc.). We will define these into separate module name SpringTokenRoles. We will add functions which grant different roles like Owner and minter. Also, a require function that will check if an address has the specified role or not. As a resource can not be copied, we have to borrow it, so we will define the function which will let us borrow different roles.
module SpringTokenRoles {
resource Owner { }
resource T {
minter: bool,
blacklisted: bool,
}
public publish() {
let sender: address;
sender = get_txn_sender();
if (true) {
Self.grant_owner_role();
}
move_to_sender<T>(T{ minter: false, blacklisted: false });
return;
}grant_owner_role() {
move_to_sender<Owner>(Owner {});
return;
}public borrow_owner_role(): &R#Self.Owner {
let sender: address;
let owner_role_ref: &mut R#Self.Owner;
let owner_role_immut_ref: &R#Self.Owner;
sender = get_txn_sender();
owner_role_ref = borrow_global<Owner>(move(sender));
owner_role_immut_ref = freeze(move(owner_role_ref));
return move(owner_role_immut_ref);
}
}Similarly, we will do the above implementation for other roles i.e. minter, blacklisted with few more functions available below.
The above functions work similarly to a require statement in Solidity. You can find rest of the token implementation from Springrole’s GitHub
Conclusion
Most of the people will find writing a smart contract in Solidity to be easy as it is loosely based on ECMAScript. Prior knowledge of the same would be helpful in understanding Solidity.
Clarity is Lisp-like language, so people with prior knowledge of Lisp will find Clarity to be the go-to language to write smart contracts.
For those familiar with Rust programming language will prefer to code in Move as it is very similar to Rust.
Every smart contract language has its pros and cons.
I believe Solidity is the way to go for more flexibility. However, if you need immunity from reentrance attack, you can try out Move and Clarity, and if you want to take advantage of the first-class resource types then look no further than Move.
About SpringRole
SpringRole is enabling everyone’s #VerifiedProfessionalProfile on the Blockchain. It is a decentralised attestation-based professional network platform powered by the blockchain.
SpringRole is the platform where people can view, share and get attestations on their professional profile, thereby creating a verified resume that they can share and use. A user’s educational qualifications and work experience are verified by the organisations themselves and written directly to the blockchain. To assess a user’s skill set, SpringRole has a system of weighted endorsements that let users objectively look at people’s profiles and assess their skill level.
Learn More
To learn more, and be up-to-date about all-things-SpringRole:
