FAQ

What is Flow?

Flow is a fast, decentralized, and developer-friendly blockchain. Brought to you by the team behind CryptoKitties, Flow is the foundation for entire ecosystems of consumer applications starting with games, collectibles, and the apps that interact with 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 billions of consumers around the world.

Will Flow be decentralized?

Absolutely. If anything, Flow will be even more decentralized than current networks by making it easier to participate in the consensus process that secures the network.

Will there be a Flow token?

Yes. All decentralized blockchains use cryptographic tokens (cryptocurrencies) to ensure the security of the system. Flow is committed to a diverse and decentralized participation in the Flow Network, and therefore the distribution of the token, in compliance with securities law and other relevant regulatory frameworks. We will be working with our legal team, player-base, and developer community to find efficient and equitable ways to give our most dedicated early adopters access to the network. We need you to give us feedback as developers, players, and netizens of the world so, sign up on withflow.org to learn more.

When will Flow be ready?

Flow will be ready for action in 2020!

Will you keep building on Ethereum?

Ethereum is an incredibly important project and both CryptoKitties and Cheeze Wizards have smart contracts that will continue to live on the Ethereum network. Dapper Wallet will also continue to be compatible with Ethereum, so we will continue supporting the ecosystem. That said, it’s likely that future applications intended for mainstream audiences built by Dapper Labs or its partners will be built on Flow.

What about my Cheeze Wizards?

Cheeze Wizards is optimized in both scale and user experience for the current crypto community, and so all Wizards will also remain with their smart contracts on Ethereum. Wizard NFTs will only be created during special time-limited tournaments, meaning they will continue to be extremely rare. Just like CryptoKitties, Wizard owners will be able to use Dapper Wallet to access games and apps built for their Wizards on Flow.

What will happen to my CryptoKitties?

CryptoKitties NFTs and their associated smart contracts will continue to live on Ethereum. As the most decentralized smart contract platform currently in existence, Ethereum is a safe place to track the ownership of valuable assets like CryptoKitties and other collectibles. Once Flow is live, CryptoKitty owners will be able to use Dapper Wallet to take their CryptoKitties into applications on Flow, benefiting from the universe of games and other apps that can run there.

What will happen to my Dapper Wallet?

Dapper Wallet will support Ethereum and Flow, allowing consumers to access assets and applications on both networks. Active users of Dapper Wallet will be the first to receive early access to test or play with upcoming experiences on Flow.

When can I start building on Flow?

We want to work closely with creators to build vibrant application ecosystems on Flow: get in touch through our signup form for early access to the Emulator.

What is composability? Why does it matter?

Composability refers to developers building on top of shared resources such as an existing user base, data, security and running code. “A platform is composable if its existing resources can be used as building blocks and programmed into higher order applications. Composability is important because it allows developers to do more with less, which in turn, can lead to more rapid and compounding innovation.” – Jesse Walden, 4 eras of blockchain computing

Technical

How is Flow different from other blockchains?

Flow was explicitly designed to support games and consumer applications on day one, with the throughput necessary to scale to millions of active users.These goals necessitated a number of significant technical innovations:

  • A pipelined architecture that separates the jobs typically done by a single miner or validator across five different node types, significantly reducing redundant effort and improving efficiency.

  • A new cryptographic technique we call Specialized Proofs of Confidential Knowledge (SPoCKs) to address the Verifier’s Dilemma.

  • A single shared state for all smart contracts, ensuring that each transaction has full ACID guarantees. This unlocks rich interactions between smart contracts (“Composability”) and creates strong network effects for apps built on Flow.

Flow was exFlow also introduces a series of important design choices to improve usability for developers and consumers alike. See the How Flow Works section of the Primer for more details.

How will Flow deal with the overhead of providing state proofs for a high volume of transactions per second?

The Flow Architecture defines an Observer role specifically to provide cryptographic proofs of transaction outcomes. Client software works with Observation Nodes to provide users with a view of the network that is accurate and secure, without requiring those clients to keep up with the torrent of traffic flowing through the entire network.

The number of Observer Nodes in the network has no fixed limit, which will support a practically unbounded number of light clients fetching full state proofs.

What are SPoCKs?

Specialized Proofs of Confidential Knowledge (SPoCKs) are a new cryptographic technique developed by the Flow team, formally defined in our Technical Papers. SPoCKs allow any number of provers to demonstrate to a third-party observer that they each have access to the same confidential knowledge. These proofs are non-interactive and don’t leak any information about the confidential knowledge itself. Each prover’s SPoCK is specialized to them, and can’t be copied or forged by any other prover.

Flow uses SPoCKs to address the Verifier’s Dilemma by requiring Execution and Verification Nodes to “show their work”. In order to get paid, these nodes need to provide a SPoCK showing access to confidential knowledge that can only be obtained by executing all of the transactions assigned to them.

How difficult will it be to port a dapp from Ethereum to Flow?

All smart contracts and decentralized applications (“dapps”) built on Ethereum today share two important characteristics: they are architected assuming an ACID development environment, and they are written in Solidity, the programming language of the Ethereum Virtual Machine (EVM).

The first property holds on Flow: all dapps and smart contracts on Flow can assume a single shared state space, and don’t need to be rearchitected to support a sharded environment or asynchronous function calls.

The second property does not: while the EVM was a massive improvement over non-programmable blockchains, even Ethereum is moving towards a more flexible and performant programming model. Flow will not directly support the EVM, and you can expect more details about the Flow programming model this fall.

How will Flow get past the limitations of processing a high volume of transactions on commodity hardware? Can’t you overload an SSD with just a few hundred TPS?

The workhorses of the Flow architecture are the Execution Nodes. You shouldn’t simply think of Execution Nodes as fast computers; each of them is likely to be an entire cluster of high-end server hardware colocated in a professional data center.

Execution Nodes are super fast and have very high staking requirements, but are only ever entrusted with executing the deterministic block transition function. All of the work they do is verified and confirmed by the network of Consensus and Verification Nodes.

How will Flow get past the limitations of processing a high volume of transactions on commodity hardware? Can’t you overload an SSD with just a few hundred TPS?

The workhorses of the Flow architecture are the Execution Nodes. You shouldn’t simply think of Execution Nodes as fast computers; each of them is likely to be an entire cluster of high-end server hardware colocated in a professional data center.

Execution Nodes are super fast and have very high staking requirements, but are only ever entrusted with executing the deterministic block transition function. All of the work they do is verified and confirmed by the network of Consensus and Verification Nodes.

How can the Verification Nodes check the work of the Execution Nodes if they aren’t as powerful?

Collectively, the Verification Nodes will confirm every part of the block computation many times over, but each individual Verification Node will only do a fraction of the work. For example, if there are 1000 Verification Nodes, each Verification Node would only need to check 4% of the total block for the entire block has been inspected 40 times over. Our Technical Papers provide the full details and security analysis of this approach.

What about the Scalability Trilemma? It says you can’t have security, decentralization, and scalability at the same time!

The Scalability Trilemma is an important conjecture made by Vitalik Buterin that is not formally proven, but is almost certainly correct for homogenous blockchain designs. If every node in the network has the same role, you have to compromise on at least one of those dimensions.

Flow doesn’t “break” or disprove the Trilemma, it dodges around it. The trick is noting that, if we let different nodes participate in different roles, we can choose the right trade-offs for each part of the system.

Flow maximizes security and decentralization for the Consensus Nodes, the part of the system most vulnerable to Byzantine attacks. This limits their scalability, of course, but that isn’t actually a problem because we don’t ask the Consensus Nodes to do anything computationally expensive.

On the other hand, we crank up the scalability for Execution Nodes to dramatically increase computation throughput. This compromises the security and decentralization of those nodes, which we address by ensuring that every step of every transaction is confirmed by the high security and decentralization Verification Nodes.

For each node type, the Trilemma holds as expected, but the overall effect is a system where the weaknesses of one part of the system are more than offset by the strengths of the other parts.