Is EOS smashed?
I have to say that EIDOS is a very smart design, it kicked the BM's ass.
Why is it that it kicked BM's ass instead of EOS's ass? Because strictly speaking, EOS as a public chain, an infrastructure, a network consisting of direct connections from super nodes, has always been running well, effectively providing blockchain services.
According to EOS New York, the “EOS main net is almost paralyzed” by the major media is actually an exaggeration or even a misunderstanding. EOS has never been paralyzed, just you can't afford it. According to the data from https://eosflare.io/, the peak value of TPS is only 910, and there is room for EOS design capacity.
The problem is not in the network performance of EOS, but in the design of BM. The original resource strategy of the chain is not designed to serve the application better, but for marketing. Higher turnouts (community management), completely free use, etc., these gimmicks are indeed eye-catching. Based on such a starting point, there is a strategy for allocating computing resources based on the amount of mortgage. The following questions are all from this.
(1) Resource instability
CPU, NET is obtained by mortgage EOS, it is unstable. Simply put, when more people mortgage more EOS to get the CPU, NET, your resources are diluted. For example, let's assume that there are 3 seconds to perform the transfer. If you mortgage 100 EOS to get CPU resources, I mortgaged 200 EOS to get CPU resources. I am 2:1 for you, then the system will Assign 2 seconds of CPU resources to help me do things, 1 second of CPU resources to help you do things; then when extremes happen, I mortgage a lot of EOS to buy the CPU, let's say I am 1000:1 for you, then you only have very Less CPU is executed. At this time, you may use more EOS to buy the CPU. When everyone does this, the CPU price becomes huge, and everyone is in a vicious circle. It is possible that a CPU with 0.1 EOS collateral can complete a transfer, and in a competitive environment it will become possible that 100 EOS collaterals are not enough to complete a transfer.
(2) The cost of learning for ordinary users has increased sharply
Originally, the blockchain threshold has been very high, and this design of BM has increased the difficulty. DAPP is more difficult to promote and can only compete among stock users. As a normal user, such as Plaza Aunt, she not only has to understand the public key, private key, but also CPU, NET, RAM. Even if she got the CPU hard, such as 10 ms. This is awkward, what concept can be said that ordinary people can hardly understand. What is even more ridiculous is that it is actually changing. It can still be used for 10 ms today, and it may become 0.01 ms tomorrow. Even ordinary transfers can't be done. How do you let ordinary people use it?
(3) Is EOSREX serving small and medium-sized retail investors?
Due to the large amount of EOS being mortgaged, it is difficult for small retail investors to get computing resources to use DAPP, which seriously affects the promotion of DAPP. At this time, BM did not reflect on the resource allocation strategy, but introduced another ambitious design EOSREX, which was intended to allow large customers to lend EOS to retail investors to obtain computing resources, and then use DAPP. But how can the interest rate of the big family be better than the rate of return? Not some small and medium-sized people are eating this chicken rib. The chicken ribs are chicken ribs, there is always some meat. However, the product itself has a financial design flaw that exposes the risk of maturity mismatch to users who purchase REX. That is, when you want to get it back, REX doesn't necessarily sell it. It is hard to imagine that big families will participate.
Of course, EOSREX as a DeFi product is not a big deal. It just wants to use it to patch the resource strategy. It is inevitable that it will be wishful thinking.
(4) There is no primary or secondary business
The core functions are not prioritized with common applications, and stability is worrying. Specifically, the case of EIDOS is that when a nuclear bomb-level MLM application like EIDOS goes online, the core functions are instantaneous. But technically, EOS is not awkward, but you are too poor to afford. Looking at the people's exchanges and increasing the CPU mortgage, you can guarantee that the transfer business is basically unaffected. One side is said to be free, and it is expensive to use. Is it very split? BM is a good interpretation: free is the most expensive.
(5) "Garbage" DAPP's paradise
Any DAPP can be deployed to the chain at a low cost, but it can act as a catalyst, causing an infinite amplification of the chain, exposing the entire chain and other applications on the chain to risk.
Can Ultrain solve this problem?
Before answering this question, we must first declare that the above analysis of the EOS problem is only for the singularity of BM resource management. EOS as an open source project, technically, we still appreciate it.
The reasons for EOS congestion have been resolved from multiple perspectives. The fundamental problem is the resource design of the EOS chain, not the throughput. Ultrain avoided these issues from the beginning of the design.
(1)Ultrain's multi-chains architecture mode
Ultrain adopts a multi-chains architecture mode which is the main and side chains. The main chain is not deploying DAPP, focusing on the transfer of core assets UGAS and the management of side chains.
DAPP is deployed on the side chain, so even if you want to deploy an application such as EIDOS to Ultrain, it will not affect core functions such as transfer.
(2) Innovative resource management allocation model
Although the application of the nuclear bomb level does not affect the core function of the main chain, does it have any effect on the side chain it deploys?
The answer is that the impact is small.
Ultrain is a service provider that distributes resources to DAPP in a pre-sale manner. The capacity of any DAPP is limited by the amount of resources purchased. This pre-sale resource is stable and inelastic. It is a strict sandbox that locks DAPP inside. Any DAPP can only affect side chains within this range.
This time, EIDOS actually only costs a very small amount of cost to deploy DAPP, as small as can be ignored, really empty gloves white wolf. What really destroyed EOS was the speculators of countless wool, who took up a lot of resources and launched a DDOS attack on EOS.
This is not the case with Ultrain, which is completely limited by the resources it purchases. If its business geometry increases, but does not replenish the resource package in time, then the DAPP itself will be congested, downtime, and will not affect other applications of this side chain.
(3) How does the resource flow?
Careful people may have noticed that Ultrain's several technical weekly reports have repeatedly mentioned the resource market, which is designed for resource circulation. Assuming that EIDOS wants to expand, it must enter the market to purchase packages from other DAPP service providers and use real money to compensate other affected DAPP service providers.
Regarding the resource market, we will give you a more detailed introduction after the function is launched.