Since the introduction of smart contract technology, Solidity has been the coding language of choice for smart contract developers. However, if you’re a Solidity developer, you already know it has drawbacks. Among other flaws, major security concerns can arise from the simple mishandling of certain data types, and there are no built-in access controls. A new smart contract language developed for the Flow blockchain, , learns from Solidity’s oversights and natively solves many of its inherent problems. And if you already know Solidity, it’s straightforward to learn! Cadence This article introduces the Cadence smart contract language, details how it improves over Solidity, and then walks through a side-by-side comparison of both languages on some common smart contract examples. By the end, you should be comfortable with Cadence and ready to get started on Flow! About Cadence Cadence is the programming language that powers the Flow blockchain, which was originally created by to support large-scale crypto games and NFT projects. (You’ve probably heard of NBA Top Shots—one of their most successful projects.) Its syntax might be familiar, since it was inspired by popular modern languages such as Swift, Rust, and Kotlin. Cadence is and , with a resource-oriented approach and capability-based security model. Dapper Labs statically strongly typed All of this means that Cadence is . highly optimized for digital asset creation and management The most substantial innovation Cadence introduces is its . This approach makes it significantly easier to create, track, and manage a user’s assets. Instead of relying on a central public ledger as the source of truth (as Ethereum does), assets are tied directly to a user’s account storage. So an asset created as a resource, such as an NFT, can only exist in one location at a time. This ensures they only have one owner—either an externally owned account or a smart contract. resource-based paradigm How Cadence Improves Over Solidity Cadence improves over Solidity in many ways. Let’s look at three examples—small coding mistakes, security and access control, and contract deployment. Those small coding mistakes Some of the biggest issues with Solidity usually stem from the smallest mistakes. For example, initializing a variable with just a default value—although convenient at times—can lead to unexpected results if that variable is not changed. And fixed-range data types can lead to potential underflow or overflow situations, which would be disastrous if that data type represents a monetary value. In Cadence, variable values must be set upon initialization, removing any unwanted results from default values. Additionally, integers in Cadence are automatically checked for underflow or overflow conditions, whereas you would need to inherit OpenZeppelin’s or use a version higher than 0.8 with Solidity. safe math library Security and access control When it comes to security and access control, Solidity requires you to create custom modifiers or inherit other security-based smart contracts, but also has many functions that are public by default. With Cadence’s , accounts can only perform functions they have access to. This means Cadence has access control fundamentally built into the language itself. Also, methods defined on resource objects in Cadence cannot be susceptible to , something Solidity developers have to be keenly aware of when creating the flow of their logic. capability-based security model reentrancy attacks Smart contract deployment When issues in Solidity smart contracts are found, developers are unable to fix them without deploying an entirely new contract. And even then, the vulnerable contract still exists. Developers must ensure their user base switches over to the new contract. In Cadence, is built in and transparent. When the code is declared secure and final, the contract can be made immutable by removing the keys from the owner of the smart contract. smart contract upgradeability Overall, Cadence is a safer and more secure smart contract language that leaves less room for error. Now let’s look in detail at the differences between smart contracts written in Solidity and Cadence. We’ll walk through a simple Hello World contract and then a more complicated NFT implementation. Simple Contract Let’s start with an all-time classic. We’ve all written “Hello World” in multiple languages, so it’s an easy intro to Cadence. Let’s go through it step by step. Contract Definition First, we have the contract definition. The obvious difference is that the Cadence contract has an access control modifier: in this case, pub. This modifier ensures that everyone in the Flow network can access the contract, the default behavior for Solidity contracts. However, in Cadence, we could also set the access control to . This limits contract access to the . Here we already see a major difference between Flow and Ethereum. We don’t simply deploy contracts to the Flow blockchain; we deploy them to our account storage. On the Flow blockchain, each account is initialized with storage, where resources and structures can be stored. This storage has its own permissions, which allows us fine-grained control over who can execute the methods of our contract. access(account) account that deployed that contract Contract Variables The next line defines a string variable scoped to our contract. Semicolons are optional in Cadence, and a keyword is used to define the variable. let Cadence has two types of variables—mutable and immutable. Variables created with are immutable, or otherwise known as constants; we can only set them once, and they cannot be changed for the lifetime of the contract. We define mutable variables (ones that can be changed) with the keyword. let var In this case, we set the variable value in the init method, because Cadence ensures that this method is only called once for every contract deployment. Methods The Cadence equivalent to Solidity’s is the method. This method is called exactly once—at the time a contract is deployed. constructor init Inside the init method, we set the value for our greeting variable. While Solidity writes to contract variables by default, Cadence writes to local variables and requires you to use the self-object to access contract variables. This decision protects against you accidentally writing to a contract variable when making a typo. The second method of our contract returns the greeting variable. In both Cadence and Solidity, we have to declare access for the method to be public, and both languages require us to define the return type. In this case, it’s a string. But Solidity requires us to be more low-level here. It requires us to explicitly tell it where the string is located. It also makes us mark the functions as view, so that we don’t accidentally modify the state of the blockchain. Cadence, on the other hand, doesn’t need that low-level control, since it is strongly and statically typed. Potential errors are caught before the program is run on-chain, making the whole method declaration more readable by removing redundant keywords. NFT Contract Next, let’s look at a basic NFT contract from both languages: Since both languages have different approaches to this example, let’s look at them separately: first walking through the Solidity example, then Cadence. Solidity In Solidity, an NFT is basically a list of IDs. You must keep track of these IDs inside the smart contract and increment them manually to ensure uniqueness. Solidity doesn’t know anything about NFTs or their uniqueness. It’s just a list of IDs mapped to their owners, all managed manually within the contract. This leaves room for error if the ID incrementation is improperly handled, potentially resulting in multiple NFTs having identical IDs. In the example, the NFT doesn’t have any additional data attached, but you could add another mapping ID to a URI. The contract ensures every newly minted NFT is mapped to an owner's address. This is a simple example, of course. Usually, you would need to extend several interfaces to get a remotely secure NFT contract and features like metadata used to attach the well-known JPGs to your NFT, but the basic mechanisms are the same. Cadence Now, let’s look at the Cadence version and how it improves upon this Solidity example. Resource Definition The Cadence example starts with a resource type called . Notice the @ symbol in front of ? This symbol is required, as it ensures the usage and behavior of resource types will remain explicit. NFT NFT We can create instances from a resource, and it can have attributes just like a struct. The difference from a regular struct is that a resource is a special type that handles ownership in addition to the data it stores. Inside the resource type , there is an id field. The field is an integer, , and it is a unique id given to each NFT resource. This will be different for each NFT resource, meaning the resource cannot be duplicated or combined. Next, the field is initialized using the function. NFT id UInt64 id id init Similar to how ensures only one function can modify a variable, Cadence ensures the same for its resources. Rust’s borrow checker Resource Creation When we create a new resource, we have to move it around storage locations. Our smart contract will not run properly if we leave the resource as is, so this forces us to be deliberate with resources and their storage locations. This form of control also ensures that resources never get lost or accidentally deleted; they can only be in one location at a time. When we call the mint function, it will create a new instance of our resource. This function returns a resource with a type of and takes in the field, , from the resource that was defined earlier. The keyword is a bit like the new operator in object-oriented programming, creating a new resource. The , or move-operator, makes it explicit that this resource isn’t available at the source after we called it. NFT NFT id create <- Storing the Resource The variable will point to the account we used as a deployment target for our contract. As we learned before: smart contracts aren’t deployed in a global namespace on the Flow network, but in special on-chain storage that belongs to your account. So, the smart contract knows which account it’s been deployed to and can use that information in its methods. self.account In this example, we use the account’s save method. In the final function, we move the resource into the methods first argument and tell it which path inside the account should store our NFT. init save Since our NFT is a resource, no entity on the Flow network can copy it; we don’t have to keep track of its uniqueness explicitly. Summary Cadence is a fresh take on smart contract programming languages, optimized for asset creation and management. It’s a modern alternative that mitigates the deficiencies of Solidity through such means as forced management of variables and resources, security and access controls at a foundational level, and the ability to upgrade smart contracts before making them immutable. Cadence opens you to the possibilities of the Flow ecosystem, and incorporates many features from languages like Rust. So, if you are a developer looking to write smart contracts in a fundamentally safer and more secure language, Cadence is an excellent option. To learn more, check out the and . Cadence Documentation Flow Developer Portal Have a really great day!

Too Long; Didn't Read

Discover Saakuru: Web3 Mass-Adoption with 0-FEES

Smart Contract Head to Head — Ethereum vs. Flow

Too Long; Didn't Read

John Vester

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Smart Contract Head to Head — Ethereum vs. Flow

Too Long; Didn't Read

John Vester

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES