Since the development of the first blockchain database named “Bitcoin”, complex transaction behaviour was a “Holy Grail” for people wondering how they could pay, bet, play, and even order pizza with such assets.
The first complex transaction logic implementation was made available right in “Bitcoin” with a stack virtual machine providing a limited set of operations for the end-user to make some fun with it. Fine example is an Omni-layer built on top of the operations set, which end-user intention is to provide a creation and usage of the custom user-defined assets. Such a system successfully fulfilled contemporary requirements for liquid asset transfer. Unfortunately, such an application logic usage rapidly overflowed the throughput available, so no mass adoption happened.
Another attempt to provide the customizable complex transaction behaviour was made with creation of “Ethereum”, which provided some created from scratch programming language called “Solidity” for creation of even more complex application logic, hoping it would not overflow the database throughput. Obviously this lead to another failure. Primal language and naive database architecture understanding did not survive the reality check - in 2017 the protocol was literally down with CryptoKitties hype.
The scalability troubles got up again, so another popular solution was rapidly proposed. It’s name was EOS. The solution was to split the computable transaction complex behaviour and to process it with the set of cluster nodes, which were called “Block producers”. This lead to the entrustment of an enourmous responsibility to these “Block producers”. They were now not only about data storage providers, but also computation providers. Now these guys not only store and process your data, but they even define the way your transaction behaves itself, define if they allow such a transaction to be written or not. Futhermore, such an “improvement” lead to the unacceptable database node hardware requirements, which made the support truly awful. Moreover such a split was not enough for building production-ready applications - who would like to find out if the upvote transaction, which was even payed for, was at first queued and then rejected?
Yeap. The following blog post series is about the CyberWay (https://cyberway.io) - improved and refactored EOS fork.
So what is CyberWay particularily about?
First of all the backward compatibility is held. The code contains most of the tolerable EOS parts, but excludes the awful ones. So-called “Smart Contracts” API backward compatiblity is held too, but the insides have changed. That means every EOS application could easily become the CyberWay-based one and vice versa. Enough of that. Next.
EOS’s bandwidth distribution is closely related to the amount of asset the particular user owns. Furthermore, it requires for the user to hold the asset to be available for the usage at any time. That means the asset becomes a highly valuable, but also it becomes the non-available for the newcomers one. So no newcoming applications are welcomed to be built with EOS.
Striving to eliminate these inconveniences Cyberway introduces some changes.
The bandwitdh accounting is split to the couple of categories:
EOS’s state storage is extremely unreliable and does not ensures that data is saved and restored after restart correctly. Futhermore EOS does not provide any convenient API, but supposes the data structure stored inside would be complex.
CyberWay solves these troubles. CyberWay uses the external DBMS for the state storage, which means the particular developer favourite query language can be used and the external well-designed replication and clusterisation mechanisms, done by real engineers and scientists, are also about to reduce the hardware costs and make life easier.
Because of the storage internals being factored out the separate service, the additional transaction contents-based event engine implementation is required. It is now impossible to alert the CyberWay executable from the various database if something happened or not, just like it was in EOS. Monitoring-purposed event engine, implemented as a part of updateable application, takes back the ability to track changes coming with every transaction, even if the data storage is completely outside.
Just like EOS, CyberWay requires for the transaction behaviour to be updated easier, than updating the whole cluster software. That is why the WebAssembly engine is used for the virtualization purposes and with C++ as primary language for the application development.
Why don’t just patch EOS?
Several troubles are about the data itself, and not the code:
EOS’s custom transaction behaviour is stored inside the huge hash-table allocated over a shared memory and the access is provided with an interface, based on quite sofisiticated executable logic, which also costs.
The obvious solution - to make a cache service and process the data all inside it - is also quite a task because:
Applications are welcomed to use the following.
Shared bandwidth sets a limit for the user activity based on its’ staked asset amount, but no less than some basic threshold. This is required to prevent spam to database from the newcomers, and redistribute more computational resources to the succesful application developers.
Shared bandwidth is accounted separately for the network, RAM and CPU usage.
Coming to accounting - this is done with particular application bandwidth balance, which shares the convenient part for the user performing the transaction. That is why this is called “Shared” bandwidth. The application is a multisignature account, which requires at least one additional signature from the particular user, for its’ bandiwidth to be used.
This type of bandwidth allows CyberWay to provide applications with free on-boarding of users at early stages via CyberWay Acceleration Program. Later successful application could get CYBER tokens within Acceleration Program from special fund.
Priority-based bandwidth is required for the user to surely write the transaction. It is formed with the amount of core asset staked by the particular user and guarantees the transaction gets written right at next replication time. The whole amount of staked core asset forms the bandwidth market.
Each account gets a share from the whole bandwidth market according to the amount of core asset the account has staked. Considering the case some user owned and staked the significant part of the whole bandwidth supply means the reduction of the resources available for other users. This is definitely not something requiring applications want.
That is why CyberWay introduces the prioritization of the bandwidth. That means the bandwidth gets split to a couple of categories:
How do account earn the priority?
There are couple of ways:
The guaranteed/prioritized bandwidth split ratio is set by the cluster validators.
Cluster RAM is something the applications require to work. In contrast to EOS, CyberWay supposes the RAM to be rented from so-called block producers, but not to be owned. The rules are the following:
In case the memory rent time is up, but there is still some user data stored inside, the archive operation is introduced. Block producers are in charge of initiating such an archivation and the restore is available for the user for the price median-valued among block producers.
Inspite of existing so-called “blockchain” databases, CyberWay does not intend to implement the database management software and uses the external DBMS as a state storage for more reliability. For now, only MongoDB is available, but in case of requirements, more are coming. Such a configuration considered to be troublesome for managing, but more reliable in long term.
Embedded state storage is also available in CyberWay. RocksDB is used for the in-memory and in-daemon storage management component that is faster than MongoDB.
As the state storage engine is incapsulated and factored out of the controller daemon, the event engine is implemented as a helper application, syncronizing and managing the data in external storages.
The input of such an application is a transaction set, each of which gets registered as “processed” and only after this the data are unpacked to state storage.
Such an approach allows to make sure the routine data operations are processed as required and to split the data managing daemon to single-responsibility micro-services.
Every created account is not identified with a key as other databases do, but it gets a unique 8 byte identifier encoded in base32. Also a human-readable 63 byte length unique names are available for the assignment for every user. In case of the amount of such names is greater than one, it gets charged and called a “Domain Name”.
Every domain name can be auctioned from base protocol or created by owner of a lower-level domain name. Domain names are transferable and reassignable. Therefore, a need for conversion between a domain name and account identifier gets satisfied with a newly introduced sufficient mechanism as much as need for domain transactions. Domain transactions are transactions which get applied to the data only related to the particular domain-name/application.
Protocol properties are also got changed comparing to EOS’s ones.
First of all, block generation time is increased for achieving more stable node replication. EOS’s 0.5 second block replication time is fine for most application in case of all the nodes are located in the same datacenter. But for truly distributed protocol, this requires to be increased due to increased network latency. CyberWay supposes the block replication time to be 3 seconds.
Block producers are the key members of a protocol. They keep the database safe and consistent and get rewarded for that.
Inspite of EOS’s 21 default block producers, in CyberWay the number of block producers is to be increased up to 101 in the future. This is required for more decentralization to be achieved.
CyberWay consensus algorithm is heavily inspired by Tezos’ and Cosmos’ one. So, active users are rewarded for voting and non-active users are punished for not voting.
Every account is allowed to vote for several validators with staked tokens.
Block producer’s weigh is determined as follows: w = m / sqrt(S), where m is a number of votes for any particular candidate, S is a total number of votes for any particular candidate (or number of stakes tokens as 1 vote is 1 token)
A particular block producer receives a reward from the emission and redistributes a share of it among his supporters. In case of misbehavior, e.g. a block omission, the block producer as well as his supporters are fined. The staked tokens are burned. This novelty makes block producers more responsible, and voters more careful and thoughtful.
The block producers get a share of emission. The share depends on the total amount of staked tokens. The more tokens are staked, the less inflation is. Thus, the CyberWay has in-built incentives for users to participate in governance via voting. Moreover, the passive users are diluted as they do not get any rewards from validators.
What if some user considers another user to understand better, which block producer is the best service provider? This gets covered by CyberWay with a proxy mechanism which ensures that some user could delegate his own assets to another user called “Proxy”. The proxy user gets fees for its service.
In contrast to EOS, CyberWay completely removes any inequality between the users. There are no privileged accounts, no so-called “Constitution”, no blacklists.
Workers are the mechanism first introducted in BitShares. These are users, who get their issuance share for making improvements for the protocol. The improvement can be registered and referenced by any user, particular improvement to resolve is selected via voting by validators.
CyberWay is one more fork of EOS, specified to handle more complex applications with more decentralization available. Workers are considered to be the most powerful tool for decentralized protocol improvements. The scalability and performance CyberWay introduces is fine enough for running complex social applications or financial service apllications or gaming applications. The absence of censorship and priveledged accounts makes CyberWay even more decentralized, which is coming in the next blog post.
Get the latest posts delivered right to your inboxSubscribe
<blockquote><em><em>Enjoy a second post in our comic-strip <a href="https://economy.p2p.org/category/Eli5/">style Eli5 series</a> covering loss of rewards, stopping baking and redelegation in Tezos blockchain.</em></em></blockquote><p>Arthur is having dinner with Kate, a colleague from work. They get on very well and talk about a lot of things about themselves. They discover they both have the same opinion about banks - they are crypto-enthusiasts.</p><figure class="kg-card kg-image-card"><img src="https://economy.p2p.org/content/images/2020/09/1.jpg" class="kg-image" alt srcset="https://economy.p2p.org/content/images/size/w600/2020/09/1.jpg 600w, https://economy.p2p.org/content/images/size/w1000/2020/09/1.jpg 1000w, https://economy.p2p.org/content/images/2020/09/1.jpg 1280w" sizes="(min-width: 720px) 720px"></figure><p>Arthur and Kate share their experiences with PoS tokens. They both love Tezos as an up-and-coming network.</p><p>Arthur: Who is your delegator? I have been with P2P Validator since 2018. I love their intuitive dashboard - I can see my rewards and rewards history at a glance.</p><figure class="kg-card kg-image-card"><img src="https://economy.p2p.org/content/images/2020/09/2-1.jpg" class="kg-image" alt srcset="https://economy.p2p.org/content/images/size/w600/2020/09/2-1.jpg 600w, https://economy.p2p.org/content/images/size/w1000/2020/09/2-1.jpg 1000w, https://economy.p2p.org/content/images/2020/09/2-1.jpg 1280w" sizes="(min-width: 720px) 720px"></figure><p>Kate: Oh, I really struggle to find out my rewards. My delegator is terrible at keeping me in the loop. I discovered they didn’t pay my rewards on time or in full. It’s a real headache.</p><p>A: Be carefull, maybe in future they may not pay at all. Why not change? It's really simple.</p><figure class="kg-card kg-image-card"><img src="https://economy.p2p.org/content/images/2020/09/3-1.jpg" class="kg-image" alt srcset="https://economy.p2p.org/content/images/size/w600/2020/09/3-1.jpg 600w, https://economy.p2p.org/content/images/size/w1000/2020/09/3-1.jpg 1000w, https://economy.p2p.org/content/images/2020/09/3-1.jpg 1280w" sizes="(min-width: 720px) 720px"></figure><p>K: Won't I lose my rewards while I’m redelegating?</p><p>A: No, your rewards from your old baker must be paid to you in full even when you stop baking completely. If you redelegate, your new baker will start to pay your rewards automatically when they are due.</p><p>K: That sounds great! How do I get started?</p><p>A: It’s easy, just follow these simple steps:</p><figure class="kg-card kg-image-card"><img src="https://economy.p2p.org/content/images/2020/09/4-1.jpg" class="kg-image" alt srcset="https://economy.p2p.org/content/images/size/w600/2020/09/4-1.jpg 600w, https://economy.p2p.org/content/images/size/w1000/2020/09/4-1.jpg 1000w, https://economy.p2p.org/content/images/2020/09/4-1.jpg 1280w" sizes="(min-width: 720px) 720px"></figure><p>step 1: Open your wallet and select your delegating account</p><p>step 2: Press Delegate than Update delegate buttons</p><p>step 3: Confirm with Ledger and enter P2P Validator address, finally Confirm once more.</p><p>K: Do you recommend that I choose P2P Validator?</p><figure class="kg-card kg-image-card"><img src="https://economy.p2p.org/content/images/2020/09/5-8.png" class="kg-image" alt srcset="https://economy.p2p.org/content/images/size/w600/2020/09/5-8.png 600w, https://economy.p2p.org/content/images/size/w1000/2020/09/5-8.png 1000w, https://economy.p2p.org/content/images/2020/09/5-8.png 1280w" sizes="(min-width: 720px) 720px"></figure><p>A: Absolutely. They are extremely efficient, have a great track record and only charge a fair validator fee.</p><p>K: You’ve sold them to me. How about coming up for a cup of coffee and help me to do it now.</p><p>A: This will be the beginning of a beautiful relationship!</p><figure class="kg-card kg-image-card"><img src="https://economy.p2p.org/content/images/2020/09/6-5.png" class="kg-image" alt srcset="https://economy.p2p.org/content/images/size/w600/2020/09/6-5.png 600w, https://economy.p2p.org/content/images/size/w1000/2020/09/6-5.png 1000w, https://economy.p2p.org/content/images/2020/09/6-5.png 1280w" sizes="(min-width: 720px) 720px"></figure><p><em><em>In our next story you will learn about Proof-of-Stake (POS) and staking. Let us know what you think and make suggestions for topics you would like us to cover.</em></em></p><p><em><em>Let’s stake together!</em></em></p><p><strong><strong>Website:</strong></strong> <a href="https://p2p.org/?utm_source=Tezos1post&utm_medium=creds_link&utm_campaign=blog">p2p.org</a></p><p><strong><strong>Stake XTZ with us:</strong></strong> <a href="https://p2p.org/tezos">p2p.org/tezos</a></p><p><strong><strong>Twitter:</strong></strong> <a href="http://twitter.com/p2pvalidator">twitter.com/p2pvalidator</a></p><p><strong><strong>Telegram:</strong></strong> <a href="http://t.me/p2porg">t.me/p2porg</a></p>
from p2p validator
<blockquote><em><em>Enjoy our first light-weight post of <a href="https://economy.p2p.org/category/Eli5/">Eli5 series</a> covering a reward distribution in Tezos blockchain in the form of comic-strip style story.</em></em></blockquote><p>John has some Tezos tokens and wants to receive rewards. He takes them to a baker*, P2P Validator.</p><figure class="kg-card kg-image-card"><img src="https://economy.p2p.org/content/images/2020/09/1-1.jpg" class="kg-image" alt srcset="https://economy.p2p.org/content/images/size/w600/2020/09/1-1.jpg 600w, https://economy.p2p.org/content/images/size/w1000/2020/09/1-1.jpg 1000w, https://economy.p2p.org/content/images/2020/09/1-1.jpg 1280w" sizes="(min-width: 720px) 720px"></figure><p>John makes an agreement to delegate his tokens to P2P Validator and becomes a delegator.</p><figure class="kg-card kg-image-card"><img src="https://economy.p2p.org/content/images/2020/09/2-2.jpg" class="kg-image" alt srcset="https://economy.p2p.org/content/images/size/w600/2020/09/2-2.jpg 600w, https://economy.p2p.org/content/images/size/w1000/2020/09/2-2.jpg 1000w, https://economy.p2p.org/content/images/2020/09/2-2.jpg 1280w" sizes="(min-width: 720px) 720px"></figure><p>The tokens remain in John’s wallet, but the staking balance of P2P Validator increases.</p><figure class="kg-card kg-image-card"><img src="https://economy.p2p.org/content/images/2020/09/3-2.jpg" class="kg-image" alt srcset="https://economy.p2p.org/content/images/size/w600/2020/09/3-2.jpg 600w, https://economy.p2p.org/content/images/size/w1000/2020/09/3-2.jpg 1000w, https://economy.p2p.org/content/images/2020/09/3-2.jpg 1280w" sizes="(min-width: 720px) 720px"></figure><p>P2P Validator bakes John’s tokens for 7 cycles (typically 21 days).</p><figure class="kg-card kg-image-card"><img src="https://economy.p2p.org/content/images/2020/09/4-2.jpg" class="kg-image" alt srcset="https://economy.p2p.org/content/images/size/w600/2020/09/4-2.jpg 600w, https://economy.p2p.org/content/images/size/w1000/2020/09/4-2.jpg 1000w, https://economy.p2p.org/content/images/2020/09/4-2.jpg 1280w" sizes="(min-width: 720px) 720px"></figure><p>After 7 cycles John can see on P2P Dashboard by how much his tokens have grown.</p><figure class="kg-card kg-image-card"><img src="https://economy.p2p.org/content/images/2020/09/5.jpg" class="kg-image" alt srcset="https://economy.p2p.org/content/images/size/w600/2020/09/5.jpg 600w, https://economy.p2p.org/content/images/size/w1000/2020/09/5.jpg 1000w, https://economy.p2p.org/content/images/2020/09/5.jpg 1280w" sizes="(min-width: 720px) 720px"></figure><p>It worked! John started getting rewards on his delegator address as soon the 7th cycle was completed (typically 21-23 day). The delegating process continues afresh and compounds automatically, so John’s reward tokens work with his original stake to increase his rewards in the next cycle.</p><figure class="kg-card kg-image-card"><img src="https://economy.p2p.org/content/images/2020/09/6.jpg" class="kg-image" alt srcset="https://economy.p2p.org/content/images/size/w600/2020/09/6.jpg 600w, https://economy.p2p.org/content/images/size/w1000/2020/09/6.jpg 1000w, https://economy.p2p.org/content/images/2020/09/6.jpg 1280w" sizes="(min-width: 720px) 720px"></figure><p>P2P Validator receives 9.95% validator fee and uses it to pay for:</p><ul><li>server time & running costs</li><li>building better infrastructure</li><li>24/7 technical support</li></ul><figure class="kg-card kg-image-card"><img src="https://economy.p2p.org/content/images/2020/09/7.jpg" class="kg-image" alt srcset="https://economy.p2p.org/content/images/size/w600/2020/09/7.jpg 600w, https://economy.p2p.org/content/images/size/w1000/2020/09/7.jpg 1000w, https://economy.p2p.org/content/images/2020/09/7.jpg 1280w" sizes="(min-width: 720px) 720px"></figure><p>P2P Validator is part of a tezos network, which is a decentralised one. There are many validators (bakers) in the network and each one makes their own decision on what fees to charge. If a fee is too low there is a risk to the baking process. We believe in charging a fair fee for a good service. Choose P2P Validator and get:</p><ul><li>First reward 40% faster</li><li>Efficiency 101.18%</li><li>Payout accuracity AAA+</li><li>Baking Bad rewards insurance</li></ul><figure class="kg-card kg-image-card"><img src="https://economy.p2p.org/content/images/2020/09/8.jpg" class="kg-image" alt srcset="https://economy.p2p.org/content/images/size/w600/2020/09/8.jpg 600w, https://economy.p2p.org/content/images/size/w1000/2020/09/8.jpg 1000w, https://economy.p2p.org/content/images/2020/09/8.jpg 1280w" sizes="(min-width: 720px) 720px"></figure><p>In our next story you will learn how to redelegate (change a baker) and how to stop the delegation.</p><p>Let’s stake together!</p><p><strong><strong>Website:</strong></strong> <a href="https://p2p.org/?utm_source=Tezos1post&utm_medium=creds_link&utm_campaign=blog">p2p.org</a></p><p><strong><strong>Stake XTZ with us:</strong></strong> <a href="https://p2p.org/tezos">p2p.org/tezos</a></p><p><strong><strong>Twitter:</strong></strong> <a href="http://twitter.com/p2pvalidator">twitter.com/p2pvalidator</a></p><p><strong><strong>Telegram:</strong></strong> <a href="http://t.me/p2porg">t.me/p2porg</a></p>
from p2p validator