Based on different governance concepts, the EOSC community optimized the EOSIO election mechanism, launched the EOSC main network at Genesis Height 1, and continued to iterate and upgrade the EOSC main network, making EOSC continue to evolve towards a decentralized high-performance smart contract platform, laying the foundation for the large-scale popularization of the crypto economy.

Background

The crypto economy has ushered in a critical stage from social experiments to large-scale commercial use.
Behind large-scale commercial use means huge transaction pressure. To efficiently carry huge transaction demands, a blockchain system must first provide sufficiently strong performance. To achieve this, higher requirements are required for the full node, such as better configuration of hardware machines, greater storage capacity, more stable network, faster bandwidth, lower latency, etc. Obviously, the high threshold for the full node will lead to a decrease in the number of block-producing nodes that can operate stably. If the POS mechanism is used in such a blockchain system, the system will quickly converge to a centralized situation. To strike a balance between high performance and decentralization, the DPOS consensus algorithm is undoubtedly the best choice at present and the best solution for managing a small number of nodes.
EOSIO based on DPOS consensus algorithm came into being, and the community saw the dawn of large-scale commercial use of the crypto economy for the first time. Whether the election mechanism is fully effective is the key to the survival of the DPOS consensus mechanism, and it is also related to whether the DPOS consensus mechanism can relay POW to lead the next generation of encryption wave.
In order to accelerate the arrival of the era of large-scale commercial use of the crypto economy, the EOSC community optimized the EOSIO election mechanism, launched the EOSC main network at Genesis Height 1, and continued to iterate and upgrade the EOSC main network, so that EOSC continues to evolve towards a decentralized high-performance smart contract platform.

Consensus mechanism

EOSC follows the consensus mechanism of EOSIO, namely DPOS BFT Pipeline Consensus. Unlike EOSIO, EOSC does not adopt the mode of EOSIO with one block every 0.5 seconds and one node generates 6 blocks. Every 3 seconds in EOSC, nodes will not generate blocks continuously. Although nodes can reduce the waiting time for unpacked transactions, the current network environment is often not ideal, rapid block generation will affect the stability of the chain and cause a large number of micro forks.
The current consensus mechanism of EOSIO is not perfect enough, but as a DAPP platform, block confirmation time is not the first priority of chain optimization. For EOSC, consensus mechanism must be considered in a high-load environment. In the current situation where the parallel computer system is not perfect, hastily improving the pipelined confirmation mechanism is very problematic.
The future consensus mechanism of EOSC will evolve in parallel from two directions
1. Compatible with EOSIO development and update its consensus algorithm. We judge based on the current development progress of EOSIO. When EOSIO completes parallel improvement, the consensus algorithm will be upgraded to achieve faster block confirmation time.
2. Other consensus mechanisms based on confirmation numbers will be adapted to supplement the existing DPOS consensus. On the one hand, the interaction between the embedded Layer 2 chain consensus and the main chain will be realized. On the other hand, a more decentralized cross-chain mechanism can be achieved with other consensus mechanisms.

EOSC technology improvement

Resource model based on handling fees
Although EOSIO's CPU and NET resources payment model is a good design in technology, it is too complex for users and cannot promote DAPP developers to optimize their contracts. On the other hand, the purchasing method of EOSIO's RAM will lead to certain hoarding behaviors, which is not conducive to the development of the DAPP ecosystem. For this reason, EOSC innovatively designed a new resource model. Through practical optimization, it explores the resource model based on handling fees in a complex smart contract environment to completely solve the resource problems that plague the EOS ecosystem.
First of all, EOSC pays the user's CPU and NET resource consumption in a handling fee mode. For the action defined by the developer in the DAPP, DAPP developers can set the required handling fee for the Action. The system controls the use of the Action based on this. On the one hand, this facilitates users to understand the consumption of resources, and on the other hand, it also strongly promotes DAPP developers to optimize the use of contract resources, so that the entire ecosystem can develop healthily.
EOSC uses a cloud rental host to allocate RAM resources in a manner similar to that of renting cloud hosts. Users can pay the expenses of renting RAM resources by using voting dividends, so that users do not need to worry about rent payment, and also eliminate the problem of rent arrears. Through the "renting and selling" method, EOSC can effectively avoid speculative behaviors against RAM resources, so that the development of DAPP does not have to be disturbed by RAM prices, and effectively promote the construction of DAPP ecosystem.
While boldly innovating and exploring new resource models, EOSC also explores the mechanism to be compatible with EOSIO resource models. For CPU and NET resources, users can pay fees based on dividend age to achieve the effect of obtaining CPU and NET resources similar to EOSIO mortgage. For RAM, users can achieve the effect of EOSIO based on market purchase through staking voting interchange, so that DAPP developers can quickly enter EOSIO from other EOSIO chains and smoothly turn to EOSC resource model.
Smooth update mechanism
EOSC's election mechanism encourages super nodes to actively participate in promoting technological upgrades. Unlike the split of the EOSIO community node version, EOSC actively promotes technological upgrades and updates in practice.
In order to achieve a smoother incompatible upgrade process, EOSC has added a set of update mechanisms based on the height of the effective block. The community can confirm the height of the effective block of a function through multiple signs, so as to decentralize the smooth upgrade process. Unlike EOSIO's recently proposed tagging scheme based on block expansion data, EOSC's update mechanism is more friendly and conducive to understanding. EOSC's first practice of the decentralized "soft fork" update process in the EOSIO-based chain, which is the basic guarantee for EOSC to continue to evolve to solve various mechanism problems.
On the other hand, the function of setting chain attributes based on multiple signs can provide the community with a set of decentralized chain configuration and on-chain schemes. Various parameters and configurations can be decentralizedly modified according to actual development, so that the community can develop better.
Node heartbeat mechanism and stable block output interval
In order to promote the stability of the main network, EOSC strengthens the construction of alternative nodes from the perspective of economic model. At the same time, EOSC adds a node heartbeat mechanism on the chain to promote nodes to strengthen and improve their stability and promote more stability of the entire main network.
Based on the heartbeat mechanism, EOSC can confirm the operation of the node, so that the faulty nodes are punished based on the chain, thereby further urging the construction of nodes and preventing the instability of the nodes from acting in the entire main network.
The block generation interval time is increased at the beginning of startup, so as to avoid occasional soft forks on the main network when the current network infrastructure is not yet perfect. The half-second block generation interval designed by EOSIO and the mechanism of connecting six blocks to one node can certainly improve the chain availability in the future, but it is not applicable in the current network environment. With a pragmatic attitude, the block generation interval time will be increased first, and after the conditions are mature in the future, it will be changed to rapid block generation. This can effectively reduce soft forks. At the same time, the reduction of the number of blocks can greatly increase the synchronization rate of the whole node, so that there can be more full nodes, thereby enhancing the availability of the entire network.
More Contract Layer APIs
In order to make it more convenient for DAPP developers to develop contracts, some APIs have been added and some specific adjustments have been made to the system contracts.
First, an API to obtain the block height is added, and developers can easily and efficiently obtain the current block height. Based on this API, contracts can effectively avoid blocking block attacks and other retry-based attacks. Secondly, an API to obtain chain configuration information is added, and developers can adapt various parameter corrections and chain upgrades to the chain at the contract layer, so that the contract can also smoothly follow the chain upgrade function. Finally, in order to avoid counterfeit currency attacks, independent core token contracts are used before the chain is started, so that users can clearly distinguish counterfeit currency attacks.
Adapting cross-chain services
At the beginning of the launch, the Force team foreseeed that the support for cross-chain will be the basic function of public chains in the future. Therefore, the Force team launched the development of the Codex project and established the Codex.Relay relay chain to provide relay services for each chain, so as to realize the cross-chain mechanism between each chain, which can provide more complete support for Codex.Relay. Through the super nodes of the two chains operating each other, a "complete" cross-chain mechanism can be achieved, that is, the degree of decentralization of any chain will not be reduced during the cross-chain process.
Through the cross-chain mechanism, great scalability can be obtained. Based on relay services, Layer 2 sub-chains can be added. Some services and DAPPs with high resource consumption can be run based on sub-chains, and the calculation results or core states can be synchronized to the relay services. In this way, special sub-chains such as storage, computing, DAPP, and random numbers can be added to expand functions.
The highly customizable EOSIO blockchain development framework
Based on relay services, it can add Layer 2 sub-chains. In the future, various sub-chains will play a great role in the EOSIO ecosystem. However, it should be noted that currently, the blockchain project with customized functions based on EOSIO still has a high threshold. For this reason, the Force team has launched the Codex.io project, which is a highly customizable EOSIO blockchain development framework, lowering the development threshold of sub-chains and providing developers with a more economical and friendly sub-chain development experience.
The Force team has accumulated a lot of experience in developing blockchain based on EOSIO during the development process, and also hopes to give full play to its greatest value. Codex.io is an "out of the box" EOSIO blockchain development framework. Developers can quickly start a chain based on Codex.io. After simple configuration, they can customize various symbols and freely select economic systems and resource models. On this basis, developers only need to pay attention to the problems that the chain itself needs to solve. According to this, they can choose to implement them based on contracts or chain native layers. Codex.io can facilitate developers to expand in the native layer of the chain to solve some performance problems, and can also greatly expand the functions of the chain.
Codex.io integrates the expansion functions proposed by most EOSIO chains. With an inclusive attitude, Codex.io allows developers to freely combine on-chain functions: including minimum living security system, account system, various black and white list mechanisms, common governance mechanisms and voting mechanisms, and various plug-ins.
Through Codex.io, a large number of Layer 2 sub-chains will be integrated in the future, which will provide infinite expansion.