The Power platform is a three-layer distributed ledger technology system (DLT) for high-speed interactions processing in a decentralized public environment.
The platform is based on 3 key technologies:
All available nodes of the system are automatically divided into parallel, partially isolated distributed systems — shards.
Each such distributed system is formed depending on customer requests, which brings scalability and flexibility in the implementation of service parameters.
Shard is a practically independently working DLT system, in which the stored data and calculations among all the nodes of the shard are constantly over and over negotiated.
Each iteration of the negotiation is recorded in a data block, which is included in a blockchain by referring to the previous block.
To ensure a qualitative superiority in the coordination process within shards, a proprietary development of the matching algorithm is used — the consensus algorithm Resonance.
The new consensus mechanism belongs to the classic BFT (Byzantine fault tolerance) consensus, in which all participants must know each other`s cryptographic keys.
Resonance has a number of important key differences:
You will find a more detailed description in the technical documentation of the project — YellowPaper.
An important feature of the platform is an automated decision-making system for creating and reorganizing shards. Thanks to this system, which we named the Management Layer, the entire set of platform nodes can quickly respond not only to all sorts of standard processes in the system, but also to destructive ones: connection loss, external and internal attacks. The Management Layer connects all nodes of the platform and provides flexibility in the provision of services by the platform.
At the Management Layer, nodes solve the following tasks:
In addition, our platform implements a mechanism that protects the system from internal attacks. Without such a system, which we call the Validators Layer, if the attacker can get the majority in separate shards, he can destructively affects the entire platform. However, with Validators Layer, the platform can only be successfully attacked if the attacker gains control of more than half of the nodes of the entire platform, and not a separate shard.
Finally, the primary level of the platform is the Shards Layer. All working transactional interactions and smart contracts are executed here. For various purposes, public, private and dedicated shards are formed.
Due to the described key features of the technology, the platform has a number of important characteristics:
Bandwidth is more than 100,000 transactions per second. In the future it will be increased.
High scalability due to sharding.
Transaction processing time is less than 1 second due to synchronous consensus.
High resistance to censorship inside the shard, thanks to synchronous consensus.
High security of transactions between shards, thanks to Validators Layer.
Formation of public, private and dedicated shards in a single address space, thanks to the architecture of the platform.
Flexible economy, the ability to adapt the economy of shards to specific needs.
Configurable privacy level for platform users.
Unlike a number of projects, the project team did not use EVM (Ethereum virtual machine), but created its native Power_VM virtual machine on Wasm.
“WebAssembly (Wasm for short) is a binary instruction format for a stack virtual machine. WebAssembly is designed as a portable compilation target for high-level languages, such as C / C ++ / Rust, which can be deployed on the web for client and server applications. ”Wikipedia
Wasm is the result of many years of joint work by the W3C group, which brings together Microsoft, Google, Apple and Mozilla.
Wasm is being developed primarily for use on the Web, however, the Roadmap mentions both IoT applications and multi-threaded heavy applications.
Wasm is compatible with the LLVM (Low Level Virtual Machine) family of compilers and is optimized for data volume. If the device has a version of such a compiler, as on most modern smartphones, Wasm can be launched on this device.
At the moment, the alpha version of Power_VM is written, a shell that links programs on the Wasm with The Power blockchain. Thanks to it, our smart contracts can be compiled into Wasm code, entered into the blockchain and run inside The Power testnet. We have already tested smart contracts - counterparts of the ERC-20 standard.
For our smart contracts from Wasm-compatible languages, we chose Rust — for a number of reasons:
After writing additional documentation in the future, programmers will be able to write smart contracts both in C and C ++.Create smart contract
Dear colleague, if you write in Rust, C or C ++, and you are interested in trying your hand at writing smart contracts - please leave your contacts and we will contact you.
In February 2018, a network of 3 shards for partners was launched, with tools for developers: Wallet, Faucet, Explorer, API.
Thanks to these libraries, programmers can use our blockchain without plunging into its device, encryption, code.
In the GitHub repository you will find detailed instructions for connecting to the test environment and API documentation.
We have added a new feature to the smart contract - interface. This allows delivery of guaranteed client code to client devices, which eliminates the possibility of code substitution and human interaction interface. Thus, we are creating a new standard - an interface for interaction 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 front-end is securely connected to the server part, which is the 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 application. However, we point out that the smart contract verifies the originality of the client part and its location address. Now you don`t 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.
After the user signs a transaction, it changes the status of the smart contract on the blockchain, and the frontend of DP 2.0 can immediately receive and display this change without involving additional servers. Therefore, such a system can be called serverless.
The first DP 2.0 was created as a demonstration of the concept - this is the Survey application, which you can find in the Marketplace.
Despite the fact that the basis of the platform is a lot of shards, for the client, working with it should look the same as working with the generalized blockchain platform. For this, it is necessary that all shards operate with a single address space of clients. By declaring a single address space for clients in all shards, we also solve the problem of addressing between clients connected to different shards. This task becomes the task of finding customers in shards and routing between shards.
Therefore, the client who sent the transaction no need to worry and find out in which shard the transaction recipient is located, when the recipient shard receives information about the client`s transaction, all this is assumed by the internal shard processes.
Unlike platforms in which the client’s address is a cryptographically processed public key, on The Power Platform, a common account registry is used to provide a single client address ledger. This scheme allows you to get great opportunities, with a small complication of the system:
Automatic sharding + shard management by Management layer.
Management layer: registration of the user (account), registration of shards, registration of private shards, registration of nodes, appointment of examning nodes (validators), nodes punishment. In the Management layer, transactions are checked by all nodes of the system, therefore, this is an expensive interaction.
Shards layer: all classic transactions that exist in regular classic blockchains
Now there are no well-established parameters by which shardings are compared, each project has its own characteristics.
However, our CTO, Igor Belousov, proposed his classification for distributed systems with sharding. Below is a table comparing known platforms.
Note: not all information was published by some of mentioned projects.
|The Power||Zilliqa||Quarkchain||Pchain||Chainweb (Kadena)||Polkadot|
|System state type|
|System state type||Mixed state||full state||Sharding state||Sharding state||Sharding state||Sharding state|
|Cross-chain transactions transfer method|
|Cross-chain transactions transfer method||Direct transfer||Main chain||Main chain||Main chain||Direct transfer (?*)||Main chain|
|Cross-chain transactions validation method|
|Cross-chain transactions validation method||Additional and delayed verification||Full state|
|Main chain||Main chain||Additional verification (?*)||Additional and delayed verification|
|Chain management system|
|Chain management system||Majority decision||Main chain||Main chain (?*)||Main chain||Majority decision||Main chain|
|Node features||Peer nodes||Privileged nodes in the “main” chain||Privileged nodes in the “main” chain||Peer nodes||Privileged nodes in the “main” chain|
|Platform account type|
|Platform account type||Single||Single||Meta-account|
If there is a main chain in the system, this means that the speed of validation of any transaction is equal to the rate of validation in the main chain - 2-3 minutes in general. There is an opinion that when there is a main chain, these are actually different blockchains combined in one platform, and not a single blockchain network.
State refers to all system parameters at the moment (all accounts, the amount of funds for them, smart contracts and their status). If the state is full (for example, in the Zilliqa project), all nodes must store all the information that is energy consuming. Easier validation here is the main advantage. Sharding state - each shard works completely separately, validation takes considerable time. We have a mixed state type. Part of the data (state of shards, accounts belonging to shards, state accounts, private shards, whick nodes are validators) is stored on all nodes. And the data that is processed is stored inside the shard.
Cross-shard transactions (between shards) - in most projects go through the main chain, but in our system - directly.
The most important difference is there is no leader in the shard, a block is created collectively by all nodes. In the other consensuses, the block is usually created by the leader node and then confirmed by the others.
Thus, we reduce the number of coordination steps and, most importantly, completely remove the possibility of censorship, the seizure of control over the shards management is possible only if more than half of the nodes have colluded.
Since all nodes can submit their information, we are going to use mandatory actions to create additional sources of entropy to create a randomizer as close as possible to reality. We enter into each block such data from each node that cannot be predicted, because these data are signed with their private keys, and it is problematic to hack them. On each block new data is entered signed by keys.
Reduced the number of matching steps to 3.
The maximum number of nodes in a shard is no more than 150. BFT protocols work as quickly as possible on a small number of nodes.
Technological decentralization is achieved through the BFT-like protocol Resonance
Economic (socio-economic) decentralization is executed through the PoS (proof-of-stake) algorithm. It is beneficial for the owner to protect his node from seizure and not economically profitable to compromise the system.
Unlike mining, minting does not require calculation, the node receives a reward for the very fact of block creation.
Validators are changed every 1 hour (every 3600 blocks).
When a block comes from someone else`s shard, the present validator knows which a validator is responsible for it (we described above what is included in the full state). If more than 50% of validators have signed a block, then the validator decides to do so.
Shard status data is stored in two other shards. The last 2-3 blocks may disappear, all previous will be restored.
To capture the platform management system - Management Layer, it is necessary to capture more than 50% of all nodes in all shards. This condition is similar to those working in systems with PoW. Capturing a separate shard will also lead to nothing - since all transactions of the shard are checked by external validators. And in order to confidently capture the majority of validators, it is necessary to get the majority of all nodes. Which leads us to the same indicators of security.
Protection against Sybil attack is PoS (proof-of-stake) mechanism. In order for a node to be connected to the system, its owner must send 500,000 SK tokens to a specific system address.
All components of The Power platform are written completely from scratch by the project developers, the key features of the project are patented, that protects the project its partners and customers from potential external influences, vulnerabilities or control attempts.