When to Use the Fluence Protocol

Centralized databases, blockchains and off-chain transactions - bridging them all

Blockchain is public but slow, server computing is the fastest, but neither ensures privacy. How to fulfill all these conditions?

Meet Alice, a developer considering this question. Her goal is to make an app to organize a surprise party for her friend Bob. She wants it to be private - only for the friends who prepare the party with her. She needs a list of gifts everyone’s bringing, to not repeat any items. Guests who don’t know what to buy yet could visit the linked websites for inspiration. One of the gifts is 1ETH that they all pool together to encourage Bob to get into crypto.

The app needs to allow friends to add what gifts they’re planning to buy, and read the list of all the gifts. It should also make possible updates and deletion of items. That is the basic CRUD application. CRUD stands for Create - Read - Update - Delete. These four interactions all boil down to some kind of operation between a User Interface (UI) and some Data Store. Then there are two choices for the developer - construction of the UI and of the Data Store. This article focuses on the Data Store one, UI is beyond the scope.

What are the options for data storage?

Centralized server

Alice has experience with the development of applications in Sever-Client network pattern, so she considers it first.

In a centralized server model (web2.0) the server is the sole source of truth for the whole network. The program is hosted either on your physical server, or a third party cloud provider. The latter position is occupied by a couple of tech giants, with insane economies of scale. Many people, including some of Alice’s friends, are vary of such concentration of power. Alice doesn’t want to worry about making her friends use one specific centralized service. If only they were interoperable… She also doesn’t want to put them into the position of giving up their consumer preference data.

Besides these concerns, there’s another, a technical one. For Alice’s app there is the ‘collect and transmit 1ETH’ requirement. Centralized services don’t lend themselves well to interactions with a blockchain ( the Ethereum network in this case).

Thus Alice rejects the centralized server option.

Maybe start out with a blockchain-based solution from the get-go?

The blockchain option

In a blockchain setup a decentralized ledger is the source of truth instead of a centralized server. You don’t need to trust one centralized entity. In exchange, you expose your transactions to the public. There are ways to hide them, but they require some effort. Alice wants to keep her app private for Bob not to have his surprise party spoiled, but making all the app users move to anonymized wallet setup isn’t viable.

Another cost is the speed. As every transaction or data exchange needs to be mined and verified, simple blockchains have scalability issues - limits on the number of transactions per minute. In 2019 Bitcoin had 4,5 transactions per minute while Visa had around 1700.

Off-chain transactions help solve that. They take the load off the main chain, making data transfer cheaper and faster. Besides, they protect the privacy of the transactions made off-chain.

Yet there is another disadvantage of going full blockchain in this context.

The decentralization is on the level of the ledger - nodes communicate to make sure the chain is valid. Yet the blockchain-as-data-store is a singular entity, just like a centralized server. There is one valid version of the record that is just in many copies. From the perspective of an application, it’s not that much different from a centralized server.

Erdin, Enes & Cebe, Mumin & solak, senay & Akkaya, Kemal & Uluagac, Selcuk & Bulut, Eyuphan. (2018). Building a Private Bitcoin-Based Payment Network Among Electric Vehicles and Charging Stations. 10.1109/Cybermatics_2018.2018.00269.

What if the Data Store is decentralized, yet not public? How to use off-chain computing to its full potential?

Peer to peer network

Peer-To-Peer network allows different versions of private information to exist between the nodes. There is no central authority and nodes can do computation on local data on their own, without keeping track of the global blockchain.

There are applications like this. Torrent network clients are all different nodes for the torrent network. Seeders and leechers choose which files to host; in the blockchain you process all the transactions of the network by design.

A similar example is Mastodon. It is a social networking software that you can run to create your own network, with a UI similar to Twitter. Not every user runs a node, most are clients of a server node. This federated approach is halfway between ‘every user for themselves’ of fully decentralized applications and fully centralized ‘ Big Tech’ approach.

Alice could fork the Mastodon code as many have done before. Then she could host the server node and only invite her friends to use a client. But she would need to add the Ethereum interoperability from scratch. Alice starts to consider other options, easier to implement.

Yet another example of peer to peer web3 protocol is urbit. In contrast to the previous mentions, it is not permissionless. You need to invest in blockchain-tied identity to network with peers. The barrier to entry is not an inherent disadvantage, but a tradeoff, which isn’t worth it in Alice’s situation.

Should Alice make a peer-to-peer networking stack as a fork or a copy then? Just to create one simple app?

Fluence peer to peer networking

There is no need to create from scratch. Fluence provides a framework for any p2p networking application. Fluence is a solution where apps are run on local nodes of the Fluence network. These nodes talk to each other like other decentralized applications. What is special about Fluence is that applications that the nodes run are in Aqua language, optimized for distributed systems. Moreover Aqua has specific bindings to interoperate with Ethereum, IPFS and other web3 networks, as well as with web2 APIs.

If you’re familiar with the OSI model, Fluence is basically the presentation layer (OSI layer 6), presenting data for applications to use.

Let’s say that the market changes and now the friends want to gift Bob Solana, not Ether. With Fluence there is no vendor or API lock in. With Aqua language it is easy to change the blockchain that the application uses.

How does Alice’s app work on the Fluence network?

Alice sets up a local Fluence node, runs a simple Hello World program. Then she sets up the logic of the local network consensus layer. That lets the peers (her node and connected nodes) keep track of the changes in the distributed Data Store. Next, she describes how Ethereum interaction will work. Finally, she deploys the application to her node, and sends invites to friends to join the network, installing Fluence node and her application. All is ready!

The party turns out great, Bob is happy. Alice is glad her app reached the goals.

What if Alice decides to make the app customizable? So that anyone can throw a surprise-party as she did?

Benefits to developers and hosting providers

After making some changes in the code to account for a more general use case Alice is almost ready to earn from her app.

Deployment doesn’t differ from what she did before. She doesn’t need to worry about the servers, as Fluence hosting providers are looking for great apps that will generate traffic for them.

What about the profits, though?

Fluence developers have the business side greatly simplified. Monetization works by automatically sending developers a commission when the app is hosted. This is highly valued by the original Fluence developers, as evidenced in their manifesto.

Usually, FOSS (free and open-source) developers work only part time, as their work is not monetized. Fluence solves this.

The same applies to APIs, services becoming obsolete, made paid or censored. That is not possible in the Fluence network app ecosystem.

How does it work for hosting, though?

As a hosting provider, you can be selective about which applications run on your node and talk to online peers. That is different from blockchain, where you need to validate or disqualify all transactions. This opt-in model encourages node owners to host applications that they are not using by rewarding application hosting with the native token.

That creates a healthy market mechanism regulating demand for hosting and supply of apps. Additionally, you avoid the scalability issues that blockchain suffers. Nodes trust each other on a local subnetwork for their purposes, and the write operations.

Conclusion

Alice’s surprise-party-organizer app is just an example of how a simple CRUD app with web3 integration can work on the Fluence network.

Much more complex APIs, p2p protocols and backends can be built.

Aqua language opens new opportunities for creativity by bridging web2 and web3 services.

What would you build with Fluence?

Further reading

The best place to learn more about Fluence network is their website: https://fluence.network/

Also check out the FAQ: https://doc.fluence.dev/faq/