How Cadence and Flow will revolutionize smart contract programming

Published in

Coinmonks

10 min readApr 6, 2021

By leveraging the power of resources, the programming language of Flow — Cadence — brings exciting new ideas to the ledger-centered world of smart contracts.

At the very time of finishing this article, the news broke: Dapper Labs, the company behind the Flow blockchain, just managed to secure another financing round of $305 million. To me, this didn’t come as a surprise.

Yes, obviously there is NBA Top Shot. But to be honest, there are tons of other reasons why this project looks promising: the user-friendly and developer-oriented philosophy, the innovative scaling approach or simply the great team behind the project, which has already given the crypto world such wonderful innovations like Cryptokitties (and with it the ERC721-standard).

But in my view, the real innovation lies at the core of the technology, its smart contract language Cadence. This is why I am dedicating a whole series of articles exploring the language in-depth, starting with a general overview of the core principles.

Spoiler: It’s not all about NFTs

Before diving into the details, let’s get something straight. When talking about Flow, people seem to intuitively associate it with non-fungible tokens — no wonder, given the breathtaking success of NBA Top Shot. But you’re missing out on the best part if you stop there.

One of the most disruptive aspects of Cadence is actually the implementation of fungible tokens. As such, the fungible token implementation also happens to be a great illustration of one of the main disruptive paradigms of Cadence: Resource-orientation.

In order to grasp this concept, let’s have a look at something familiar and incrementally work our way towards the new ideas that Cadence brings to the table.

Solidity and the ledger-centered approach

Let’s start with an implementation of a fungible token on Ethereum, a very naive implementation indeed. It highlights the features of what I call a ledger-centered approach or the philosophy of the central mapping.

We have a single smart contract with two functions: a mint function that allows us to print money out of thin air, and a send function, which opens up the possibility to send money to someone else. But the most important entity of this contract is the data structure at the top of the contract: The mapping of balances.

mapping(address => uint) public balance;

This is the essence, this is all we need; the data that creates value, that gives ether and takes ether. It is what essentially constitutes every fungible token on Ethereum: one piece of state. And that state, while being changed and transformed by somewhat complex contract functions, always remains the beating heart of everything: A central ledger.

Problems with central ledgers

For people in crypto, this makes perfect sense, but for people outside the space, chances are that it doesn’t. And honestly, why should it?

Yes, we may laugh at questions like “Wait, where are my Bitcoins actually stored?” or “How much Ether can my wallet hold?”. But just like the questions of a child, their answers turn out to be really hard to come by once we have finished laughing.

Let’s look at it this way: In our daily life we encounter money as a resource, something we can touch, something we can feel, something we can put under our pillow. Sure enough, when we put our money in the bank or we work in a company, we will certainly stumble upon ledgers, right. But the thing is, in our traditional money system, these ledgers all reference real-world resources, those things we can feel or touch or stash in our purse.

Unlike Ethereum. In Ethereum, as in many other blockchain networks, the ledger effectively is the currency, thereby creating a mismatch between different mental models of the user. To me, this is the main reason why newcomers to the crypto space have such a hard time wrapping their head around everything. And to be fair, the whole thing is somewhat counter-intuitive, wouldn’t you say?

Besides, the whole ledger-centric approach also gets us in some technical trouble. Let’s say we do not only own a stash of KittyCoins, but also some other tokens like DonkeyCoin and SquirrelCoin. If we want to see all the balances of all the different currencies we own, we will have to look into every single ledger of every single currency — that is every single smart contract at every single address — just to get an overview of our funds. This can be very tedious for developers and users alike, and things get even more complicated once you start interactions between different contracts themselves.

Now continue this line of thought to the criminal side of things. The central ledger poses a huge security risk. For users, it is a single store of value; for hackers, it’s a honeypot. Just think of the five-million dollar DAO-heist that almost killed Ethereum.

Enter: the resource-oriented paradigm.

The resource-oriented paradigm

Cadence shifts the paradigm from a central ledger to what I call distributed resources. Before we can look at the actual implementation, we have to talk about accounts on Flow and how they differ from accounts on Ethereum. There is a great article on this topic which you should check out:

So, How Are Accounts on Flow Different from Accounts on Ethereum?

This blog post is for developers learning about the Flow blockchain Moving forward, we'll assume that you have basic…

www.decentology.com

The key takeaway is: Unlike Ethereum, Flow does not have this idea of different accounts for users and contracts. In Flow, smart contracts (and any kind of resources) are actually stored in the account itself, and one account can store multiple smart contracts. They live in a specific sub-directory of the account and can be made public or private with certain capabilities, a topic beyond the scope of this article.

Why is this important? Because it allows for another level of digital asset ownership, where a user actually owns the resource in their account, rather than relying on an entry in an external ledger, stored in some remote smart contract.

So the interesting question now is: How does the resource look? Let’s continue where we left off and follow our fungible token example. The following is an implementation of a fungible token, taken from the Flow docs.

As you can see, this poses a fundamentally different conception of ownership design. Rather than implementing a central contract with user balances, we create the balance of a user as an individual resource — a vault. And this vault is stored directly in the account of the respective user; it is actually owned by the user, thereby completely decentralizing ownership.

In order to receive tokens, a user simply has to implement the Receiver interface (containing the deposit function) into his or her account and make it publicly callable. Any other user can then call this function in order to deposit tokens to the users vault. Conversely, in order to send tokens, a user has to implement the Provider interface (containing the withdraw function), of course this time in a private manner.

The real deal: Linear types and the move operator

The withdraw function is the place where the true magic of Cadence becomes visible, and it is in my view the most interesting part of the whole implementation. The first line of the function body looks familiar: we simply subtract the amount of tokens from our own token balance. But now on to the special part:

return <- create Vault(balance: amount)

As we can see, we do not simply send tokens and increment some recipient balance. What we actually do is create another resource in form of a vault (let’s call it our sub-vault) and we instantiate this sub-vault with the balance we want to send. As a sidenote, resources in Cadence can only be created in the scope that they are defined in, so we can instantiate our sub-vault, but we couldn’t create an instance of a resource that is not defined in our account.

This newly created sub-vault, an own resource by itself, is then sent off with the move operator (<-), a small detail with huge impact. Here is a paragraph from the Cadence docs on the move operator:

When a resource is used in an assignment, parameter, or return value, it is moved to a new location and the old location is invalidated. This ensures that the resource only ever exists in one location at a time.

In short, the move operator (and with it the use of linear types) prevents a lot of bad things happening, bad things that can very well happen in any other blockchain network when interacting with smart contracts. It effectively makes it impossible to either loose nor wrongfully duplicate resources. The resource can only live in one location at one time, guaranteed. To me, this is a game changer in terms of digital asset ownership, usability and security.

Advantages of resource-orientation

The resource-oriented approach of Cadence outlined above has a few major advantages over central ledgers.

First, the approach enhances decentralization that is at the heart of blockchain technology. If you think about it, the implementation of a Solidity-style fungible token is actually quite centralized: One contract to rule them all. In Cadence, instead of having a central point of failure, the currency is spread-across all accounts in form of resources (in this case: vaults).
Second, it enforces security. Building on the previous point, the enhanced decentralization effectively minimizes the area of vulnerability. We avoid building a central honeypot that attracts hackers. Instead of robbing one central contract, an attacker would have to infiltrate every single vault of every single user, effectively reducing the feasibility of large-scoped attacks.
Third, there is also improved usability for end-users. If the person you want to send tokens to does not have a receiver interface for this currency implemented, you can simply not call the deposit function of the account. This effectively puts an end to all those wrongfully sent and never recovered coins out there in the Ether.
Last but not least, the concept of a resource owned at the account-level is much closer to the mental models of the average user. The idea of actually possessing a vault where the tokens are stored is much more intuitive than having to grasp the idea of a ledger being the currency. It is basically like having your own purse with neatly organized compartments for the different coins your using.

So, what’s better?

We are at a critical point in blockchain evolution. The first and second cycle have proven that there are many use-cases for the technology out there that even opened the gates for large scale institutional inflows to the space. In my view, there is still one main hurdle ahead: the mass-adoption of the technology by end-users and developers alike, an adoption that goes beyond speculative involvement. And this is where Flow really shines. As we have seen, it is the smart design of the underlying technology that legitimately backs their promise of a user-friendly, developer-friendly ecosystem.

Having said that, I don’t think that Flow will be the only way forward. Let’s face it: Ethereum will not be going anywhere in the foreseeable future, especially with layer two scaling solutions flourishing now. Its ecosystem is huge and many major smart contracts are battle-tested and audited, a very crucial argument that cannot be made for any implementation on Flow just yet.

But of course, maximalist arguments almost always miss the point, and the team of Flow has (opposed to some other projects) made it very clear that they do not want to be part of the “Ethereum killer” narrative in any way.

A multi-chain future

I am convinced that the future is multi-chain, and Flow might take the first step in the onboarding of new users to the space, together with easy-to-use, semi-custodial wallets like Blocto. Covering these use-cases where blockchain technology can slowly be mixed into familiar experiences of users is a task I think Flow is very well suited to do. It also aligns very well with their overall focus and the selection of partners and product launches on the chain. If a user is more technical or a use-case requires more complex workflows, there will always be Ethereum, enabling more mission-critical, technically fine-grained implementations.

Either way, Flow is a huge enrichment to space, disrupting the current state of smart contract programming and bringing fundamentally new concepts to the table. The root of all this innovation, essentially what I wanted to show in this article, lies in Cadence, the smart contract language of Flow.

This is why I want to give a huge shout-out to the Flow-team for proposing such an innovative approach and wish them all the best for their future plans!

Join Coinmonks Telegram group and learn about crypto trading and investing

Also, Read

Get Best Software Deals Directly In Your Inbox