Recently, Daniel Larimer (aka Bytemaster) initiated a ground shattering dialogue on a potential resolution for both the privacy and performance limitation of existing blockchain infrastructure. His ultimate goal, with his paradigm-shifting idea mentioned in EOS’s telegram chat, was to achieve the following objectives:
- An utterly decentralized structure where all participants can run a full node while reaching 10million tps with no transaction fee
- No voting or stacking requirement
- No Ram or disk storage-related issues
These objectives mentioned by Bytemaster above, are “coincidentally” the limitation of EOS that persistently challenges the network. As we all know, the common consensus known as the DPOS is the heart and soul of EOS; each node participates in this network by stacking specific amount of Token, where twenty-one selected nodes to achieve consensus in a vast scale network. The blocks are generated after consensus is achieved between the selected nodes. EOS elects twenty-one nodes every round and makes a block every 0.5 seconds with 3 minutes of confirmation time. Also, based on EOS’s latest performance testing report, it reached 3000 TPS.
One state-of-the-art solution at the time still faces criticized by many; mostly in three key aspects.
The 21 consensus nodes of EOS require hardware with extreme performance. A typical EOS consensus node configuration request a CPU with 96 cores + 256G memory. Such costly setup results in a barrier to entries, a nature burden prevents participants from qualifying as consensus node and limits the total amount of consensus nodes. On the other hand, centralized server deployment is vulnerable to professional large-scale DDOS attacks — a challenging issue faced by Internet giants such as Google and Facebook. The 21 nodes of EOS shares the same concern, where hackers can access the network through DDOS attack towards the nodes, with ease! To unravel this matter, setting up the network entirely on peer-to-peer base (such as Bitcoin or Ethereum) is the most straightforward approach. The network shaped by all participating devices, where the impact of each node is equally considered. There is no practice of “special treatment,” similar to EOS with their consensus nodes. Thus, participants have every right to deploy a full-node device to join the network and implement a complete decentralized network
EOS’s current system performance relies on the system resources of the 21 nodes. Due to the characteristics of the blockchain, smart contracts need to run in parallel on these 21 nodes at the same time. EOS runs mainly through CPU. RAM and DISK which are limited resources. Not charging a fee for coding operation require EOS to lease CPU, RAM, and DISK through EOS Token stacking, to avoid the issue of system resources being wasted. This is where the dispute arises, for the number of resources are limited, scarcity immediately attracts speculative investment. Currently, on the EOS platform, a DAPP with 10,000 daily active users, need to stack staggering amount of Token; about RMB 3.5 million worth of FIAT currency, this is far more than what an ordinary DApp development team can afford, which makes the EOS platform a particularly unfriendly platform for DApp developers. This problem needs to be solved. Otherwise, it will prevent talented DApps who can’t afford such cost from running on top of the EOS platform; except for lucrative gambling application.
Although BM only mentioned his “dream” philosophy in the EOS telegraph group and did not elaborate on the detail. We are happy to find the resemblance of his design philosophy to Ultrain’s fundamental design philosophy, in fact, a perfect match! Truthfully, Ultrain has been implementing the above three aspects in both technical design and engineering execution; these functions can be found in Ultrain’s testnet, which were recently deployed. and will be launched on the initial version of Ultrain’s access network during the end of December
First of all, Ultrain is based on the RPOS consensus mechanism; an independent intellectual property created by the team. The initial design goal of achieving high TPS network has been realized in a fully decentralized peer-to-peer network. During a press released event back on July 15, Ultrain announced that it had achieved 3000 TPS on AWS while running on 1000 nodes, a performance similar to EOS, which runs a semi-decentralized environment. It is also worth pointing out that Ultrain’s network are entirely equal, and each machine can be operated as a full node.
Secondly, the RPOS consensus mechanism of Ultrain is a dream come true, each round of consensus nodes is randomly selected through VRF algorithm, where the amount of stacking tokens is only utilized as a parameter in the VRF algorithm. Different from the EOS scheme, such design prevents the selection result to be reliant on the amount of Token stacked. By doing so, Ultrain achieved a more random process, thus effectively avoiding the issue of the manipulated voting result, a noting consistent with BM’s proposal of no voting nor stacking
Thirdly, the blueprint of Ultrain’s economic system was designed to consider how to solve the fundamental problems in the existing blockchain economy: 1. The miners’ revenues will gradually decrease, which results in an “arms race” for mining rigs. 2. The usage fee for DApp developers will continue to increase with the number of uses and the price of Token, and the cancellation of the usage fee raises some eyebrows that questions if speculative manipulation is in play, if so it will cause the operating cost of DApp to be completely uncontrollable; As BM previously mentions this matter, we are here to elaborate.
To address this matter, the first step to take is to resolve the scarcity of system resources. Ultrain adopts the design strategy of employing both main & side chain. The main chain incorporates the asset of each Ultrain user, whereas the DApp is running on the various side chain. Keep in mind that the system resources between the main and side chain are isolated, which guarantees the system resources with the ability to expanded indefinitely, a new side chain can be formed whenever there is a need for DApp; The core challenge lies here is security. The number of devices in each side chain is limited compared to the whole network. To solve the question, “How to ensure the overall safety of each side chain with a limited number of the device.” Ultrain adopts what we call “random. Scheduling” another in-house independent intellectual property, the devices that make up each side chain are not static. These devices will be randomly selected and replaced through the entire network within a specified period, resulting in a system that’s decentralized with dynamic characteristic and achieve security through random selection; establishing a security environment.
Under the safeguard of “random scheduling,” DApp developers can use the network free of doubts. They only need to estimate the resources and duration they need to use Ultrain’s network and pay a fixed amount of usage fee, similar to a “package” deal we are all too familiar with. When compared to the Ethereum design, Ultrain’s DApp developers only need to pay a fixed resource rental fee for resources usage, without having to bear the risk of Token price fluctuation; and when compared with the EOS design, Ultrian’s DApp’s development costs are fully controllable due to its resolution on scarcity
As we were only able to partially introduced Ultrian’s comprehensive economic system in this article, we will aim to provide a report detailing Ultrain’s systematic tokenomics design to our audience shortly.
Overall: I am glad that Ultrain’s philosophy and approach on public chain design echo with BM’s ideology. I also encourage more developers to experience Ultrain’s testnet and take out our platform for a test-drive!
For more information, please visit https://developer.ultrain.io /
