In this post, we’re reflecting on the current state of the dapps and lay down our thinking behind the Fluence core ideas. What is the decentralised app backend, how does the app exist inside the ecosystem, is there anything we can do on the infrastructural level to boost dapps adoption? Read on!

The technology stack evolution

Let’s get the terms out of the way first. Right now, there are more than 2000 projects listed as dapps on websites like DappRadar or StateofTheDapps. When we say “dapp” we mean its original meaning, “a smart contract” plus some kind of UI. This way, we can talk about a narrower group of applications and set aside things like protocols or blockchains.

Now, if we define the dapp in this way, can we dissect it into components we’re all used to: a backend, a frontend, a database? Does it need those at all? Most traditional applications that we’re using today are built in this way. They have a frontend UI running in a browser or on a mobile platform, a backend that manages all the business logic on a remote server, and some kind of a tool to manage its data (database) running on the cloud.

Traditional app architecture: plain and simple

These terms could be applied to the dapps, but will they fit? The frontend is the easiest: most dapps have Javascript UI in the browser (and some even on mobile, check out the MEW mobile app, for example). The backend and data management are much harder to distinguish, though. The dapp is a smart contract, so it apparently runs on a blockchain which serves as both: executes the contract and stores some kind of data related to it.

And this is where a developer runs into the limitations of this model:

the blockchain Virtual Machine puts its own ground rules on what kind of code could be executed and how it should be processed;

the blockchain is tailored to store the data and keep it intact, not to manage it in a way a regular app needs

These limitations, when faced, force the developers to create workarounds and invent their own “backend” tools that could allow them to build more complex logic, manage the data properly, and perform heavy computations in real-time.

It’s better to be more specific with the problems they want to solve this way, for example:

read large amounts of data from the blockchain and store it in a custom data structure to make it easily accessible for their app;

process the data to extract the information they need (sometimes it might even be a subtask for something bigger);

create complex business logic that manages several independent components in real-time;

build “light” UIs (since the heavy computations could not be efficiently handled by the chain, taking them to the user side could be a solution but that makes the client side of the app too complex and puts the burden on the user’s machine — all of which is not cool).

The majority of the dapps today run on Ethereum and most developers have met these challenges at some point. Almost every project has to deal with “reading data of the chain“ in some way, for example.

Growth doesn’t have to lead back to centralization

As more and more projects demand the ability to read from blockchains, and full nodes are providing their services without a reward (providing access to blockchain data and returning it in a structured, consumable-for-app format), infrastructural projects emerge. A typical dapp will, at some point, have a web3.js function that sends a request to api.[whosyourfavouriteprovider].io. This is not just a conceptual problem, but a vulnerability that might backfire.

The problems with the custom-built backends and third-party tools are:

They lack something (again, this is because dedicated developer resources are limited).

They lead back to centralization (the custom backend often runs on the AWS cloud entirely, or depends on one centralized service provider).

It’s also fair to ask the regular questions anyone would ask any other app developer, like: when the app grows, how will its backend infrastructure and maintenance costs scale? As the dapp user base grows, how are they going to manage the rising demand for computational and storage resources?

Turns out, decentralized apps are not just smart contracts after all

What would happen if we took a more focused approach to fundamentally solve these problems while staying decentralized?

Blockchains are designed to be secure, let them stay that way

The limitations and what others might call “flaws” (and too often they do) in the blockchain design are actually there for a reason. The initial “Northern Star” for the blockchain design was security. A network of independent nodes behaving in a certain way to make sure the data it holds is correct and can’t be tampered with, and it does not require any third party or supervision in order to do so. Once you start adding more features while trying to keep the initial goal, you’re inside a tradeoff: more capabilities, less secure, partially centralized.

If we take a look at the majority of existing applications, most are based on Ethereum. With the blockchain size of 4TB and each computation replicated around ten thousand times, there’s not much room for the apps to grow.

A great read on tradeoffs and “The Scalability Trilemma” can be found in the Multicoin Capital blog.

You don’t have to pick just two

The best solution is to transform the system in such a way where the problem would not exist in the first place. We often take Ethereum as an example since it originally introduced the concept of dapps and has most of them, and thus, its problems are well known and the most well studied. However, to find a way out of the capability / security / decentralization trilemma, let’s leave Ethereum to what it does best — security. Its best capability is staying trustworthy even if 80% of the network is down. Let it stay that way and add another component.

Fluence: trustless, yet capable

While blockchains are super secure and, as we’ve argued above, optimised for “writes” (securely adding new transactions / data on the chain), adding another component tailored for “reads” and processing the obtained data might dramatically increase their utility without compromising the security or decentralisation parts. The “read” part should be verifiable and as secure as blockchains are by default.

Fluence allows to orchestrate the data from the blockchains in a way that an application needs and provides the guarantees provides the guarantee that the data extracted with each query is 100% valid and will stay that way until it gets to the destination point.

At Fluence, we’re building a network that is tailored to read data from various decentralized sources (not only the blockchains) and then processing and storing it in a way that would make it easily accessible for the dapps in a decentralized and cost-efficient way.

Perfectly balanced, like all things should be

As we’ve discussed above, Fluence will take the backend part:

receive and store the app related data from various decentralized sources (blockchains, storages like IPFS, and the apps themselves);

staying cost-efficient by reducing the redundancy to the absolute minimum and by keeping the data on the same node that does the processing — this way, only a few nodes have to perform the computations which does not affect the whole network and you don’t have to spend resources (time, bandwidth, computational power) to transfer vast amounts of data;

storing the data in an easily consumable format (remember part one: reading and preprocessing data from blockchains requires significant effort) which helps reduce costs even further;

having its own incentivization that rewards the nodes for providing services in real-time, meaning as fast as possible.

Coupled with secure blockchain, Fluence network allows developers to build applications in a way they are familiar with, while staying inside the decentralised architecture and its best features:

decentralized in the sense that there’s still no single entity that controls it, no DDOS or censorship threat — any node provider can join the network and rent out resources. It is completely trustless and permissionless;

all requests are publicly auditable — you can audit any request that goes through the network at any point in time. This gives the same transparency for the web apps that the blockchains provide for the financial transactions.

In addition, it’s efficient in terms of storage and computation. Any existing backend or database (with some limitations) can be potentially ported to the Fluence network. This means actually taking legacy code and moving it to Fluence without rewriting it into another language or rebuilding the architecture from the bottom up.

What’s in store?

We’re past the proof-of-concept phase. Right now, developers can play around with the demo to dig into the Fluence components, architecture, and how things work. The test-network is on the way, stay tuned!

Continue your journey with Fluence

Haven’t found what you need? Ask the community!