Flow is a relatively new blockchain and Smart Contract platform. Written by the team behind the successful game CryptoKitties, Flow's design solves most issues with running blockchain games in production environments.
Many successful DApps use Flow and benefit from a great user experience:
- Simple onboarding
- Fast latencies
- And cheap transaction fees
What trade-offs DApp developers have to consider to use Flow? How does that compare to Ethereum?
The high cost of DApps
Ethereum is the original Smart Contract platform. With considerable support from the original developer team, users and miners, it is the most secure platform on the market.
Most apps are built on Ethereum: from super complex Defi (Decentralized Finance) protocols to games. However, while most finance applications are a perfect fit for the blockchain, Ethereum is not always the ideal environment for making games.
Let see some of the problems DApps game developers are currently experiencing with Ethereum:
High latency: Proof of Work blockchains are known for long block times, low throughput, resulting in significant latencies. User actions will take some time before being included in a block and appear on the network. While it is possible to hide latencies using UI tricks, it requires more work on the developer side. People not familiar with DApps also do not want to wait for significant delays before their actions to be validated.
Expensive and unpredictable computation: gas, the unit of measurement of the computational effort on the Ethereum network, is expensive. Gas price is even higher when the network is under high load (successful DApps traffic, ICOs, spam attacks). Sometimes the cost can get so high that users would instead hold off playing the game.
Programming errors: Smart Contracts code will inevitably get complex. With more complexity, the probability of introducing security flaws is higher. In addition, errors create risks of losing assets (NFTs, cryptocurrency tokens) and pose new dangers for users heavily invested in your game.
Onboarding: most DApps fail to gain mainstream traction because of complex and not practical onboarding processes. Users need to install wallet software, create a wallet and buy cryptocurrency before interacting with a DApp. Each step creates tangible friction for users. The faster users sign in, the better!
Flow tackled these issues by making good tradeoffs and introducing a novel architecture. While the architecture details are interesting (and might come up in another article), this article focuses on understanding the impact of their choices on your product implementation.
With Flow, latencies are low thanks to a fast PoS consensus. Moreover, apps benefit from cheap transaction fees and easier onboarding.
To quickly learn about Flow, here are some resources to start:
- Flow overview: onflow.org/primer
- Docs: docs.onflow.org
- Cadence language reference: docs.onflow.org/cadence/language
A vital component of a good DApp user experience is the wallet. Typically, users expressed a strong need for:
- Clear and straightforward UI
- Fast onboarding
- Safe backup and recovery
Most Ethereum DApps are using MetaMask, a browser extension, to interact with Web3 enabled websites. MetaMask is a wallet that can work standalone or be used as a bridge with a hardware wallet.
Users must browse the website with a browser compatible with MetaMask, install the extension, create a wallet (key pairs), and backup recovery seed words before using the website. Unfortunately, these steps generate a new layer of friction that is going to surprise new users. Moreover, most users are not familiar with the safe storage of private keys, putting their hard-earned assets at risk.
Universal wallet support with Flow
Flow's approach is different: users are not required to install a new browser extension. Instead, they provide a universal wallet interface that can integrate any compatible wallet into a browser iframe. Compatible wallets must expose a web page that a Flow application will load to display the wallet UI.
Game developers are free to create their own wallet solution or use an already available one like Blocto. At the moment, Flow DApps seem to be putting their focus on custodian wallets. Custodian wallets manage user's private keys, store them on servers and protect them using a username/password combo. This is convenient because users are already familiar with this login method. However, it's important to note that users, in that case, do not really own their private keys. Therefore, these apps are still fairly centralized.
DApps should provide custodian wallets and non-custodian wallet alternatives to fit all user's needs. For example, game companies running multiple games can benefit from creating a custom wallet compatible with all their games.
Traditional apps use a simple Client and Server model. Clients are running within the browser. They display UI pages and perform API calls to the server. The server handles these calls, runs app logic, and sends a response to a client.
However, blockchain app developers using Flow must consider a different architecture for their web apps.
Most of the app state will reside in the blockchain. Any entity interested in knowing the app's current state can retrieve the information by querying the blockchain. This is similar to performing REST GET calls in a traditional API server.
Clients and servers are required to be connected to a blockchain node to gain access to the network. For example, the Flow testnet provides a public URL to connect to the network and start writing queries and transactions.
Cloud Wallet & Wallet Client
To facilitate user onboarding, this architecture is using a so-called Cloud Wallet. This wallet handles user identities, private keys and protects them with a normal user account system. Developers can choose to implement their own wallet or use an already available one like Blocto.
Building a custom wallet is a worthwhile investment if you intend to support multiple apps/games.
However, users already familiar with their own wallet solution might want to pick the one they prefer. The Flow FCL library enables support for local wallets or even hardware wallets.
For development, we recommend using the Dev Wallet.
DApps are made of a mixture of blockchain and non-blockchain logic and state. For example, in an NFT (Non-Fungible Token) application, developers can set arbitrary rules to mint (create) new NFTs when fiat money is spent using a payment processor. This event will generate transactions which will then create NFTs and distribute them. Features like this are usually implemented in an API server or a specialized minting server.
The API Server generally does two things:
Supports non-blockchain app logic: if there is a feature which is not requiring a blockchain, it will be implemented there.
Cache blockchain state: some blockchain operations are costly, such as fetching the list of all NFTs ever generated in your app. In that case, the server can perform the expensive operation, cache the result, and provide it to clients. This benefits both the client and blockchain network: clients are faster, reducing overall blockchain network utilization. Everyone wins!
Where all the magic is:
- DApp user interface
- Queries to read the blockchain state
- API calls
- Broadcast transactions (using the wallet)
With this design, some elements still rely on a centralized server: the DApp static resources, the API Server, and the Cloud Wallet. While it's possible to integrate more decentralized options, such as IPFS, to store the static website elements, it might negatively impact the overall user experience.
App developers must find the balance between full centralization and full decentralization.
We believe decentralization should be progressive by starting small and integrating more decentralized elements as your app matures. From our experience playing with DApps such as NBA TopShot and programming our own prototypes, progressive decentralization seems to be the best approach for mainstream adoption.