CyberWay as a much better EOS

CyberWay is more than just a blockchain optimized for the application developers

Cyber Way is a blockchain platform functioning on the basis of smart contracts and designed to deploy applications with decentralized management.

Despite the fact that CyberWay is built on EOS logic basis, it’s architecture differs from EOS significantly. Features uniquely provided in CyberWay are going to be covered in this post.

Staking in CyberWay

The user activity is limited in EOS-like systems by bandwidth allocated to the user account. If the user wants to be more active in the system, she/he needs to get more bandwidth. The amount of bandwidth allocated to the user depends on the stake that this user has.

The EOS bandwidth contains three types of resources: CPU, NET, and RAM. And only two of them - CPU, NET - are recoverable. In addition, the CPU parameter varies from node to node. The staked tokens are separately allocated to each specific bandwidth resource, so the user should determine and allocate resources wisely before any operations and control its usage during operations.

The system resources in CyberWay are allocated dynamically and more optimally.

In CyberWay, bandwidth contains four types of resources. These are CPU, RAM, NET and STORAGE ones. However, a user does not have to stake for them separately. When transactions are being executed, the system distributes the user's staked tokens dynamically and optimally according to the user needs and resources’ consumption rates.

In CyberWay, all four types of resources are recoverable. It means that each resource is restored over time. If a user is too active and runs out of any resource, the resource restores after some time.

DB structure in EOS is built in a similar way to RAM, and therefore does not take into account cases when a lot of operations have to be executed inside memory in search of specific data. DB structure in CyberWay is built like a file with data stored on a disk. If the data are written to Storage and there is an access to it, then DB does not go there. The bandwidth resource recovery is based on using Storage. There is an ability to store data for a long time in the Storage and not affect the node operation.

DPoS Consensus Algorithm

CyberWay`s algorithm to voting for validators is based on a model successfully adopted by both Cosmos and Tezos blockchains. Validators are selected by users (stakeholders) who stake tokens for them.

Distinctive feature of CyberWay from EOS regarding voting for validators:

A user can vote 30 times with one staked token in EOS. One staked token corresponds to one vote in CyberWay. This voting condition makes users more responsible in choosing validators.
The users who vote for validators receive a reward versus no reward at all in EOS. This particular reward is a part of the validators reward that she/he gets for blocks produced. The users are interested in voting for the most diligent validator, because the value of the user's reward depends on validators activities. The users negligent of their rights to vote are under the risk of dilution of their stakes.
The validator’s reward value depends on the number of votes cast. In Cyberway 10% from target inflation goes to validators for block production, 70% from target inflation is distributed between validators based on a voting stake distribution between them. The established share of emission becomes more equalized for both validators and stakeholders.
The number of validators in CyberWay in contrast to EOS is planned to grow to 101 inclusive. This solution will make the system more decentralized and less prone to abuses.
The target inflation in Cyberway varies from 10 to 20 % depending on a total stake that is used for voting for validators.

The users who do not vote for validators themselves can pass their voting rights to a proxy account. Any user can declare himself a proxy account ready to collect votes from other users and dispose them at its own discretion voting for the chosen validators.

CyberWay Event Model

The event model is a separate service subsystem providing user`s interaction with the blockchain in terms of collecting information about all internal blockchain events.

Although EOS already contains logic for processing events occurring on the blockchain, the architecture of CyberWay event model is developed from scratch. The fact is the EOS captures events of those operations that are in a chain of blocks only. Meanwhile the virtual operations can also be created during transactions’ processing (for instance, the operation of closing a post). These operations are not added to transactions and therefore do not appear in blocks.

CyberWay event model contains four components:

Event Engine — a plug-in that receives information from smart contracts about all events and generates messages corresponding to these events.
NATS message broker — a service component that stores event information. NATS can be configured in such a way that will allow to accept only information of interest from smart contracts (for example, to save only data on balances or only voting results).
Notifier — a messenger utility. This utility receives messages from Event Engine and passes them to NATS. Notifier provides the high reliability of the data transfer.
Prizm — a library asking for information about events in NATS message broker and sends it directly to an application website.

Unlike EOS, CyberWay event model is able to capture events on all operations, including virtual ones, and distribute it for further usage in a user-friendly form.

CyberWay Domain Names

CyberWay provides the ability to perform operations on domain names, including:

creating and handling of domain names;
creating and deleting a link of domain name to account;
changing of domain name owner;
domain name purchasing at auction.

EOS does not support any domain names. The EOS source code defines that account names with less than 12 characters and the dot are reserved for winners of the premium names auction. So, it is possible to redeem a range of IDs. In such case all names preceded by this range belong to its owner. A premium name can then be used as a namespace to create another accounts with the premium name as a suffix.
In CyberWay, unlike EOS, the total number of characters in a domain name can reach 253 pcs. CyberWay domain name consists of individual parts, separated by the symbol «dot». And each individual part can reach 63 characters. This makes it possible to create a domain for the application and create user names inside this domain. Moreover, user names can be short, beautiful and easy to read.

DBMS-based State Storage

Currently in CyberWay database management system (DBMS) is based on MongoDB. Unlike EOS, the CyberWay solution provides an ability to use DBMS tools, build replication (DB load scaling algorithms) using free access to data, and configure clients that can access data inside.

In order to improve system performance, it is planned to use RocksDB. So, CyberWay will support two types of storage — MongoDB and RocksDB. Depending on the type of storage used, setting up the blockchain node will be possible in both variants:

blockchain node with MongoDB;
blockchain node with RocksDB.

Privileged Accounts

One of the purposes of CyberWay is to give all users equal rights, as well as to exclude from the system any privileged users with more rights relative to others.

CyberWay platform (unlike EOS) does not contain in its code any software components that perform various privileged actions (such as executing a role of arbitrator). All users have equal rights and identical opportunities.

In order to create a greater decentralization and attract more users, there is no Constitution in CyberWay (unlike EOS), and no «gray» or «black» list of accounts used in EOS to restrict or completely block users from operations.

The Ricardian smart contracts have been removed from the logic inherited from EOS. So, CyberWay does not contain any privileged accounts that could control user activity.

Plans till the End of 2019

The worker's system launch

The system of workers, the one that ensures platform development by outsiders, to be launched in CyberWay. The workers will get 20% from target inflation in CyberWay. Any developer will have an opportunity to participate in the development of CyberWay blockchain. He/she will have to submit a proposal to improve CyberWay components and functionality. A technical specification should be written in advance of implementing a proposal. Depending on the relevance and complexity of the implementation proposed, the technical specification will contain either a brief description of technical solution or a detailed description of the implementation. The proposal can be implemented by either the developer who submitted the proposal, or any other user, including that one who provided his/her own version of the technical specification. If there is more than one candidate for the proposal implementation, the decision for appointment is taken by validators via voting.

The appointed developer (or worker) has to implement a proposal in accordance with the technical specifications.

The system of workers for CyberWay has already been developed. However, before launching it, it is necessary to conduct thorough testing, identify and fix all the bugs.

RocksDB-based DBMS implementation

The CyberWay blockchain node with MongoDB requires the administration of two processes — the process with the database and the process with the blockchain node. It may cause inconvenience in work of validators. The blockchain node with RocksDB, will be a monolithic service. This embodiment will not require the maintenance of any additional processes, since the database is architecturally built-in. This version will enable validators to run CyberWay on less demanding nodes in relation to RAM.

Useful links
https://cyberway.gitbook.io/en/devportal/event_engine
https://cyberway.gitbook.io/en/users/bandwidth_implementation
https://cyberway.gitbook.io/en/users/cyberway_features

cyberway plans future