, or ÐApps, require a special system design to achieve high security and reliability. In this article I am going to cover several main principles of how to properly design and implement back end and smart contracts for decentralized applications, taking as a primary example, though much of it would apply to , and other decentralized data platforms.
Article Highlights:
- How to private keys on the back end without security concerns
- How to properly design smart contracts and what to “decentralize”
- Decentralized and semi-centralized applications architecture examples
- How to deal with low-level stuff like network load and failures
It’s going to be big, let’s do it!
Decentralized Programs and Blockchain
Despite the fact that is facing a lot of and difficulties today, it’s a kind of technology which is here to stay, whether it’s , , or any other distributed technology still to come, regardless of the algorithm.
The main value that and other similar technologies bring can be generalized as follows: they allow people to write and run programs which, practically, cannot be changed after creation nor tampered with during execution. In other words, these programs always run as designed, and no single party can influence their behavior.
This definition is valid for many that exist today if we consider them as programs that define how coins can be transferred back and forth. This also explains why and many kinds of have real value: they cannot be generated out of thin air, by their defined “underlying programs”.
///… platforms, in contrast to , implement a more complex program layer, which in turn implements the execution environment allowing anyone to write their own decentralized programs on top of the platform. This user-defined programs always run as designed, without any exceptions, and their security is guaranteed by the platform.
Decentralized Applications
These secure and unchangeable programs running on a decentralized network in combination with traditional front-end and back-end technologies are what we call decentralized applications (ÐApps) today. Through some of them can be semi-centralized, a major part of activities in the truly decentralized application should happen out of a central party’s control.
To imagine what we call decentralized applications today, take any existing centralized web resource like or as an example and imagine that instead of a password-protected centralized account you have your “crypto identity” bound to the web/mobile resource.
That’s what provides you. The from this identity (a secret, having which, you can act on behalf of this identity) is stored on your local device and never goes online, making no one able to control this identity but you. With this identity, you can perform different actions in both centralized (web resource controlled by a central authority) and decentralized (which is a different network from the traditional www, the goal of which is to eliminate the central authority) networks, using the website as an access point and/or as a graphical user interface. The whole point of this “crypto identity” is that your actions are cryptographically secured, and no one is able to change what have you signed nor your signature.
Today, the computational and storage capabilities of fault-tolerant decentralized networks like , or are limited. If they were scalable, we could use decentralized networks to the whole decentralized application, including its graphical user interface, data and business logic. In this case, we would call these applications truly decentralized/distributed.
However, because those networks are not scalable today, we combine different approaches to achieve the maximum decentralization level for our applications. The “traditional” back end as we know it isn’t going anywhere. For instance:
- We use back end to host front end for a decentralized application.
- We use back end for integrations with any other existing technologies and services. Real, world-class applications cannot live in an isolated environment.
- We use back end to and process anything big enough for a decentralized network (blockchain in particular). Practically, the whole application and its business logic are stored somewhere in the world, excluding the blockchain part only. Not to mention, and similar storage layers the accessibility of files, hence we cannot rely on them without hosting the files ourselves either. In other words, there’s always a need for a dedicated running server.
There’s no way of building a secure and partially decentralized application without using a solid back end as of today, and the whole point of this article is to explain how to do this right.
(De)centralization and Tokens
It so happens that almost all decentralized applications today are built around so-called — custom-built (or just simply cloned) that drive a particular decentralized application. are simply a programmable currency or assets, that’s it.
Usually, a is a “smart contract” (a custom program) written on top of the decentralized platform like . By owning some you are basically able to get different services on a web resource or mobile app, and trade this for something else. The key point here is that the lives on its own and it is not controlled by a central authority.
There are many examples of applications that are build around : from numerous collectible games like (ERC721 ) to more service-oriented apps like , or even browsers like and gaming platforms like (ERC20-compatible ).
Developers themselves determine and decide how much control they will (or won’t) have over their applications. They can build the whole application’s business logic on top of smart contracts (like did), or, they can make no use of smart contracts at all, centralizing everything on their servers. However, the best approach is somewhere in the middle.
Back End for Decentralized Networks
From a technical point of view, there has to be a bridge that connects and other smart contracts with the web/mobile application.
In today’s fully decentralized applications, where clients interact with smart contracts directly, this bridge is narrowed down to a capabilities of , which in turn are forced to exist because of the fact that not every device can run and support its individual network node. However, this API provides an only basic and very narrow set of functions, which barely allow making simple queries nor efficiently aggregate data. Because of this, eventually, custom back end kicks in, making the application semi-centralized.
The whole interaction with the decentralized network can be narrowed down to just one or two points, depending on the application needs:
- Listening to the network events (like token transfers) / reading the network state.
- Publishing transactions (invoking state-changing smart contract functions like token transfer).
Implementing both of these points is quite tricky, especially if we want to build a secure and reliable back-end solution. Here are the main points which we are going to break down below:
- First of all, in Ethereum, events retrieval is not production-ready out of the box. Because of multiple reasons: network nodes can fail while fetching a large number of events, events can disappear or change because of network forks, etc. We have to build an abstraction layer to sync events from the network and guarantee their reliable delivery.
- The same for transaction publishing, we have to abstract Ethereum’s low-level stuff like nonce counters and gas estimations, as well as transaction republishing, providing a reliable and stable interface. Moreover, transaction publishing implies using private keys, which requires advanced back-end security.
- Security. We are going to take it seriously and face that it’s impossible to guarantee that private keys won’t ever be compromised on a back end. Luckily, there is an approach to designing a decentralized application without even a need for back-end accounts to be highly secured.
In our practice, all of this made create a robust back-end solution for which we name Gateway. It abstracts other microservices from ’s fun and provides a reliable API to work with it.
As a , we cannot disclose the complete solution (just yet) for obvious reasons, but I am going to share everything that you need to know to make your decentralized application work flawlessly. However, if you have any specific questions or inquiries, feel free to contact . Comments to this article are much appreciated as well!
Decentralized Applications Architecture
This part of the article highly depends on the needs of a particular decentralized application, but we will try to sort out some basic interaction patterns on top of which these applications are built (ÐPlatform = Decentralized Platform = ///Whatever):
Client ⬌ ÐPlatform: fully decentralized applications.
The client (browser or mobile application) talks to the decentralized platform directly with the help of “” software like , or hardware wallets like or . Examples of DApps build in such manner are , , crypto wallets themselves (, , , others), decentralized crypto exchanges like and so on.
ÐPlatform ⬌ Client ⬌ Back End ⬌ ÐPlatform: centralized or semi-centralized applications.
The client interaction with the decentralized platform and the server has little in common. The good example of this is any (centralized) crypto exchange today, like or : the currencies you trade on exchanges are simply recorded in the traditional database. You can “top up” your database balance by sending assets to a specific address (ÐPlatform ⬌ Client) and then withdraw assets after some actions in the app (Back End ⬌ ÐPlatform), however, everything you do in terms of a “ÐApp” itself (Client ⬌ Back End) does not imply your direct interaction with the ÐPlatform.
Another example is , which uses semi-centralized approach: you can do all useful decentralized actions there, but the application itself just doesn’t make sense without their comprehensive back end (Etherscan continuously syncs transactions, parses data and stores it, ultimately providing a comprehensive API/UI).
Something in between: still, centralized or semi-centralized applications.
The above approaches combined. For example, we can have an application which provides various services in exchange for crypto, allowing you to log in and sign information with your crypto identity.
Published at Tue, 02 Apr 2019 16:36:11 +0000
