A Deep Dive Into Flow: The Blockchain for Open Worlds

CoinList is excited to be working with the team building Flow, a fast, secure, and developer-friendly blockchain built to support the next generation of games, apps, and the digital assets that power them. Flow is built by Dapper Labs, the team that created CryptoKitties and partnered with us on their hackathon back in August of last year for Cheeze Wizards.  

We are not only excited to raise awareness of their next generation layer-one platform, but also to announce their upcoming token sale. We had the opportunity to chat with the Flow team and discuss what they are building.

1. To begin, can you briefly explain what Flow is?

Flow is a new layer-one blockchain built from the ground up for a new generation of consumer applications, games, and the digital assets that power them.

Flow is based on a novel architecture that achieves the performance required for mainstream applications without compromising decentralization or sharding the network. This means developers on Flow can build secure and composable applications to enable new possibilities for consumers around the world. To date, Flow has begun to onboard some of the world’s top brands, such as the NBA, UFC, Ubisoft, Warner Music Group, and Dr Seuss, and catalyzed independent developers, leading institutions, and additional infrastructure partners.

FLOW is the cryptocurrency token that powers all the activity on the Flow network – it is designed as a payment method as well as long-term reserve asset for the entire Flow economy. The token is a low-inflation and low-circulating- supply asset that is used by validators, developers, and users to participate in the FLOW network and earn rewards. It is also used to transfer fees, serve as collateral for secondary tokens on Flow, and to participate in future protocol governance.

2. Why did the Dapper team endeavor to build an entirely new layer-one blockchain instead of building on top of another existing protocol?

Before committing to building our own layer-one blockchain, especially one as ambitious as Flow, we closely evaluated all other options. We set up a scaling taskforce led by CTO Dieter Shirley immediately after CryptoKitties’ success (when we halted the Ethereum network multiple times, and were responsible for 20-30% of the “gas” spent on the network for extended periods).

We initially started by building on top of Ethereum: Dapper was the first (and still the most popular) smart contract wallet, and made big strides in improving usability and reducing onboarding friction. We also prototyped more than a dozen potential projects, bringing one to production in the form of Cheeze Wizards. We met with and evaluated multiple “layer two” scalability solutions, not finding any suitable balance of performance, security, and ease of use (for the user and for the developer).

We also met with and evaluated new networks claiming to be orders of magnitude faster and cheaper than Ethereum. Unfortunately, none were being built with the user experience of consumer applications in mind, and so basic features we as application developers expected from the protocol were not even in consideration. In addition, none had sufficient go-to-market strategies in place and we did not want to be alone on someone else’s island.

We committed to building Flow in May 2019 – after an entire year of research and development. Over the course of the year prior, we solidified the blockchain’s technical architecture, wrote the initial technical whitepapers specifying the core system, and developed a prototype that proved our ideas in practice. Now it was time to start building the production network.

3. Can you elaborate on some of the limitations you found when looking at other layer-one options?

Unfortunately, every other blockchain’s plans for scaling depend either on permanently compromising decentralization by limiting participation to high-end hardware – or on some kind of sharding or side chains. Our team recognized early on that limiting participation will lead to cartel-like behavior or regulatory capture, while approaches like sharding that break up the blockchain state make interactivity between smart contracts significantly more complex and error-prone. In other words: sharding hurts composability.

Sharding addresses scaling by fragmenting a single network into smaller interconnected networks. For things like simple transfers of tokens, it’s a fine solution.

However, sharding falls short when it comes to decentralized apps and smart contracts that need to interact with each other. It makes development immensely more challenging, and it compromises the key benefits of crypto applications:

• Composability: the ability for one app to build on top of, or leverage features from, another app
• Open ecosystems: the ability for anyone to contribute to a platform or someone else’s work on the platform and receive rewards for their work

On a blockchain with a single thread of execution, writing code that combines multiple smart contracts is straightforward. Admittedly, programmers can make mistakes and cause bugs, but it’s relatively easy to reason out how they happened and fix them. When one block of code is doing work, no other code is running; nothing can change behind the scenes. If the code needs to reference anything information elsewhere in the chain, it can do so safely.

In a sharded network, the code from one shard may have to stop and send a message to another shard to get some data managed. Before that code can continue working, it needs a response. Once the response is received, any number of things might have changed—including the very data that it was verifying on the other shard! We can work around this problem with an escrow mechanism, but in doing so, what used to be one single, simple transaction balloons into ten or twenty cross-shard interactions. Each of these transactions runs fragile asynchronous code. This code was probably written by several different engineers, any one of whom may have missed any number of possible failure modes. And if it does fail, you have to hope it fails benignly, without any adverse side effects from doing a partial rollback.

4. What are Flow’s key differentiators among competing layer-one protocols?

Flow’s biggest differentiator is that it already has functioning applications, nearly 100 committed venture-backed startups or enterprise developers building on top of it, and a burgeoning community that is catching up fast to the leader in the space.

From a technical standpoint, Flow is unique among blockchains. As one of our partners, Purdue head of research David Broecker, said to Coindesk: “If Ethereum is blockchain 2.0, then we view Flow as version 4.0. We view Flow as the blockchain technology for the mass market.” Flow differentiators include:

• Multi-role architecture: Flow’s core architecture is unique, allowing the network to scale to serve billions of users without sharding or reducing decentralization of consensus.
• Resource-oriented programming: Flow uses Cadence, a safer and faster programming environment designed specifically for digital assets and smart contracts.
• Developer ergonomics: Made by developers, for developers: Flow makes building new apps and protocols safe, fast and efficient.
• Consumer onboarding: Designed from the ground up for mainstream adoption, Flow is the only blockchain that builds usability improvements into the protocol layer.
• Built-in user-base: Top developers and some of world’s biggest brands (NBA, UFC, Dr Seuss and more) are already building on Flow, addressing fanbases in the billions

5. How does a multi-role architecture provide a superior way to scale versus other layer-one’s?

In a traditional blockchain, every node stores the entire state (account balances, smart contract code, etc.) and performs all of the work associated with processing every transaction in the chain. This is analogous to having a single worker build an entire car.

From manufacturing to CPU design, pipelining is a common technique for dramatically scaling up productivity. Flow applies pipelining to blockchains by separating the jobs of a validator node into four different roles: Collection, Consensus, Execution, and Verification. This separation of labor between nodes is vertical (across the different validation stages for each transaction) rather than horizontal (across different transactions, as with sharding).

In other words, every validator node still participates in the validation of every transaction, but they do so only at one of the stages of validation. They can therefore specialize for — and greatly increase the efficiency of — their particular stage of focus.

This allows Flow to scale to thousands of times higher throughput and lower cost while maintaining a shared execution environment for all operations on the network. In database terms, smart contracts and user accounts on Flow can always interact with each other in one atomic, consistent, isolated, and durable (ACID) transaction. This ensures good user experience and full composability, letting developers easily build on each other’s work.

6. I’d like to also touch on Cadence, the programming language that you developed. What approach did you take to building it vis-a-vis how it differs from other smart contract programming languages (Solidity / EVM)?

In the course of building CryptoKitties, Dapper Wallet, and Cheeze Wizards, we realized that there are many pitfalls when it comes to writing Solidity code; even professional auditing teams have trouble keeping up with all of the potential edge cases. We felt like there had to be a better way.

Blockchains represent a new kind of software domain, with autonomous software running on decentralized systems providing open access to all. Given that previous domains have given rise to new programming paradigms, it seemed worth asking: What is new in the blockchain domain that might demand a new programming paradigm?

In Solidity and WASM, the “scarce resources” that carry value are just data structures! With only one tool in their toolbelt, the onus of securing these assets falls solely on the smart contract engineers… at massive cost in complexity and technical risk.

Linear Types are a more restrictive form of data structure that are used in languages like Rust to improve memory efficiency and prevent certain kinds of programming errors. In Cadence, we extended the idea of linear Types into something called resource Types that have controlled creation and runtime support for tracking ownership. Resources are a perfect match for managing scarce assets; they have carefully controlled creation, they are uncopyable and unforgeable, and their destruction must be explicit and deliberate.

While Resources neatly solve the problem of scarce assets, another important aspect of smart contracts is implementing secure access control. Fortunately, there is an access control mechanism that has been studied extensively since the 1980s called Capability-Based Security (CBS). CBS controls access to secure services by using a “what you have” model of security (akin to a physical key card), in contrast to the “who you are” model of security commonly called “Access Control Lists” or ACL (akin to having your name on a guest list).

CBS systems have been shown to be easier to audit, allow more flexible access control patterns, and bypass some common security escalation problems inherent in ACLs. And the “Capabilities” of CBS systems require the same runtime controls and security restrictions as required for Resources for tracking asset ownership.

When Resources are combined with CBS to limit unauthorized access to scarce assets, a new paradigm is born. We call this new paradigm Resource-Oriented Programming, and it’s a natural fit for blockchains. The other team pushing resource-oriented programming is the Move team with the Libra Foundation – we are working with them to make sure Cadence and Move can be compatible and benefit each others’ ecosystems.

7. Can you touch on the Flow token and its design?

The FLOW token (“FLOW” or “𝔽”) is the native currency for the Flow network and the fuel for a new, inclusive, and borderless digital economy.

FLOW has several important characteristics that make it the ideal currency for the network:

1. Diverse use-cases
2. Broad distribution
3. Minimal monetary inflation

In particular, the FLOW token is the exclusive token required for staking the platform, as well as the currency in which staking rewards are paid. In addition, small amounts of FLOW tokens are required to pay transaction fees, and users are required to maintain minimum balance in order to support sufficient storage on the network.

FLOW is also the token always guaranteed to be available for apps and games on top of the Flow network. While developers are always free to generate and issue their own currencies on Flow, the FLOW token will always have the most usage, liquidity, and acceptance on the platform. Over time, FLOW may come to be demanded by consumers as a better medium of exchange and unit of account, or as having advantages as a store of value.

Because FLOW is a low-inflation cryptocurrency, it is designed to offer benefits as a collateral asset for new tokens created on top of the Flow network. This includes stablecoin and decentralized finance protocols. We have set aside 100M FLOW tokens to subsidize the creation of these protocols that will serve the Flow ecosystem. Given Dapper’s projections, using FLOW as a collateral asset means that as demand for secondary tokens like stablecoins goes up, demand for FLOW tokens should increase in a corresponding fashion.

8. NBA Top Shot is still in private beta – how can CoinList subscribers get early access?

We’d love you all to take NBA Top Shot for a spin. Just sign up through this link and you should be able to skip the waitlist.

Also make sure you join discord.gg/nbatopshot to connect with other users and get the latest updates.

To learn more about Flow, check out https://www.onflow.org/

Legal Notice

This blog post is being distributed by Amalgamated Token Services Inc., dba “CoinList,” or one of its subsidiaries. This blog post and use of the CoinList website is subject to certain disclosures, restrictions and risks, available here.