Join to Power_ecosystem!
Subscribe for Web3 Cloud updates
DCloud Infrastructure
Made Easy
no need for middlemen, third-party services or full-node management
Direct data validation
fully decentralized authorization and identification
Web3 ID service
Sharding
first layer
Cross- Shard Validation
PowerOS
Power Nodes
third layer
second layer
Energy Efficient and Low Cost
The protocol is really lightweight and optimized for low-power resources
More than one
Multiple Virtual Machines
We use the most advanced WASM VM, and EVM!
Power ecosystem allows using several different VMs at the same time even in one shard, including competitive ones
Serverless backend for full-stack dapps
Real dapps are executed in a decentralized network and have no single point of failure
We use the most advanced WASM VM, and EVM!
Power ecosystem allows using several different VMs at the same time even in one shard, including competitive ones
Serverless backend for full-stack dapps
Real dapps are executed in a decentralized network and have no single point of failure
E.g. this eliminates the problem of the sniper miners' attacks on liquidity!
Uncensored Synchronous BFT Consensus
Node(s) can't any influence on execution or transactions' order within a block.
SHARDING
E.g. this eliminates the problem of the sniper miners' attacks on liquidity!
The Power protocol has no bottlenecks
Shards communicate peer to peer without losing the consensus of the whole network
Every new shard increases the transactions' speed. More shards = more speed.
Is achieved by the patented technology of unlimited sharding invented by Power team.
Unlimited scalability of the processing speed
SCALING
special shards for storage and distribution of all frontend and static files
Decentralized Storage
Decentralized Computing
special shards for decentralized backend
No special skills are required - any web developer can access the Power Network via REST API without need for a middleman like node provider. The whole Web is just at your fingertips.
Power API: Designed for Mass Adoption
Data directly from network
The user application retrieves data directly from the Power Ecosystem. To prevent DDoS threats, it is possible to receive data from special purpose
"read only" nodes.
"read only" nodes.
Interface for mass adoption
A user-friendly interface for developers that do not require special skills allows integrating blockchain in the classic, generic applications and making them really decentralized
Auto data validation
A feature, responsible for acquiring and validating data in a trustless manner.
This ensures that data received from the decentralized network is 100%
tamperproof & integer
This ensures that data received from the decentralized network is 100%
tamperproof & integer
Web3 Cloud: Zero-Maintenance Services
PowerOS monitors the state of each shard in order to proactively and automatically re-distribute nodes between all shards to guarantee flawless continuity and high availability of service
These nodes are combined into fault-tolerant shards that operate as long as at least 50% of the nodes in the network are operational
The Power Ecosystem consists of many nodes located around the world
Low-level libraries for popular languages
Automation modules for popular UI Frameworks
Smart-contracts as a web3 backend can be written in high-level languages and then compiled into WASM code
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
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.
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.
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.
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.
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.
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.
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.
For our smart contracts from Wasm-compatible languages, we chose Rust — for a number of reasons:
- embedded tests
- simple refactoring
- universality of language
- a number of restrictions for the developer — to prevent errors when writing programs. Simply put, coding in Rust is much more difficult to write a program with errors
After writing additional documentation in the future, programmers will be able to write smart contracts both in C and C ++.
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.
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.
Smart Contracts
Trusted
Linked
Data
Linked
Data
Trust Era
2017
Blockchain & DLT
Internet Era
2000
Web & Mobile applications
Digital Era
1970
Mainframes & computers
Analog Era
Pre-1970
Paper documentation
Speed
Speed
Access & collaboration
Speed
Access & collaboration
Trust
Dapps 2.0 decentralized applications
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.
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.
Single
address
space
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:
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:
The Power of
disruptive
technologies
disruptive
technologies
Join to distributed world
Program of
joint pilots
joint pilots
In the frame of Power_hub we launched our pilot program!
All participants are international market players with profound expertise and vision. With several discussion sessions for pilot product definition and launch format, we make something that can be useful for you and for other participants.
We invite for partnership tech and blockchain based projects with an aim to solve the set of problems that blockchain tech is facing nowadays.
We invite for partnership tech and blockchain based projects with an aim to solve the set of problems that blockchain tech is facing nowadays.
All participants are international market players with profound expertise and vision. With several discussion sessions for pilot product definition and launch format, we make something that can be useful for you and for other participants.
We invite for partnership tech and blockchain based projects with an aim to solve the set of problems that blockchain tech is facing nowadays.
We invite for partnership tech and blockchain based projects with an aim to solve the set of problems that blockchain tech is facing nowadays.
In the frame of Power_hub we launched our pilot program!
joint pilots
Program of