In this document, we would like to acquaint the reader with the latest development of our project, which may change not only the blockchain market but also the market of applications as a whole — a new type of decentralized applications (DApps) — Dapps 2.0.
Smart contracts — the very first DApps
The simplest example of a decentralized application (without the interface part) is a smart contract: the code that runs inside the blockchain. Due to the fact that it is verified by all nodes, no one can fake it. The result of the check should be the same to be validated by the network. In PoW consensus, all nodes execute a smart contract at the same time, but the node that calculates the winning combination of a task or hash before others wins. In an asynchronous BFT consensus, a smart contract is fully executed only on one node, and all other nodes might verify the result of its execution. Theoretically, they can simply “tick off” checked, without performing a smart contract. Since the audit by the other nodes occurs after the execution by the main node, it takes a longer period of time.
In our blockchain, the consensus Resonance is synchronous BFT algorithm, so the smart contract is not only checked, but executed simultaneously by all nodes, which allows to reduce the time for its execution and verification.
In order for smart contracts to be used widely standards have been introduced, for example, ERC-20. The ERC-20 token is simply a call to a smart contract to transfer some data to it. This made it possible to standardize graphical and program interfaces for working with fields and functions. Graphic — to create a wallet that works with ERC-20 tokens, and software — to be able to create automated exchanges.
We use smart contracts for Wasm, because Wasm runs on almost all devices (with Javascript) and is optimized for the amount of data.
But nevertheless when we refer to “decentralized applications”, most often we mean applications with a client part, they will be discussed below.
Dapps
There are practically no real Dapps that do not interact with the outside world, except for ERC-20. The rest use a graphical interface.
Let’s take a look at the Dapp with a graphical interface on a textbook example — Cryptokitties. This application has a client side (frontend) and a server side (backend). In web applications, there is a frontend and there is a graphical interface (or graphical user interface, GUI), the function of which is performed by the primitives of the web browser. And on the server side, one part performs the calculations, and the other, the web server, sends and receives requests for the graphical interface.
The Cryptokitties application launches its website, which contains images, some logics, and the rest is “pulling” from the Ethereum blockchain.
In order to perform any actions within this Dapp, you need to use the Metamask plugin, where user stores the keys to his Ethereum network account and signs transactions to manage the cryptokitty. Through Metamask, user commands smart contract what changes he wants to make. Getting information from the Ethereum blockchain is possible only through its own node.
As we can see, such an application has a rather complex architecture. The backend consists of 2 parts: the 1st one is the blockchain, it stores information and work results (data processing), the 2nd one is the web server that sends the application interface and interprets the data from the blockchain to the frontend.
The frontend also consists of 2 parts: a web browser and a wallet (for example, Metamask). Let’s try to describe the process of user interaction with the application and the logic of the processes.
We can highlight here 3 types of entities:
Ones that can be fully controlled by the user: web browser and wallet (keys)
Fully decentralized objects, making changes in which is almost impossible: smart contract and blockchain
The infrastructure objects of the DApp developer: own blockchain node and the web server are completely dependent on specific owners, the centralized part, the target vector of attack on the application.
The main disadvantage of such architecture is a large number of attack vectors: the web server can be hacked (DNS substitution or physically), the money transfer address is changed, the node can be hacked by writing a special code, hacking additional modules to the web server, Java scripts.
Another disadvantage is the presence of centralized parts — for example, a web server and a wallet. Come to think of it “decentralized” is not quite the correct name for the existing DApps.
DApps 2.0. The simplicity of genius
We added a new feature in the smart contract — interface. Thus, we are creating a new standard — an interface between the client part (frontend) and the server part (backend). Due to this, on the basis of our smart contracts, you can build full-fledged decentralized applications, where the frontend is securely connected to the server part, which is a smart contract entered into the blockchain.
Currently, we cannot fully disclose the algorithm of interaction between the smart contract and the client part of the DApp. However, we point out that the smart contract verifies the originality of the client part and its location address.
Using Dapps 2.0 developers can focus on the client-side applications (or program interface, if we are talking about the Internet of Things, for example) and run them on smart contracts using our DApp 2.0 standard. There is no need to create middleware and backend, just write an application in Rust, C, or C ++, it will be executed by Wasm and compiled into binary code that is understandable to the browser, and will have a backend infrastructure. Of course, the part written by third-party developers must undergo a certain verification in order to be trusted. After the user signs the transaction, it changes the status of the smart contract in the blockchain, and the DApp client can immediately receive and select this change without involving additional servers.
Therefore, such a system can be called serverless.
Conclusion
After a while we’ll present you the first DApp 2.0 and Power_Store (store of decentralized applications and other decentralized products and services).
If you are an active developer, startup or innovative project, and you are interested in smart contracts or decentralized applications — we will be happy to collaborate, share experience and provide the opportunity to design your own application on the new standard DApp 2.0. Send us a request to the email info@thepower.io, write about yourself in the request and briefly describe the task or project you want to implement.