Based on different governance philosophies, the EOSC community has optimized the election mechanism of EOSIO. The EOSC mainnet was launched at genesis block height 1, and continuous iterations and upgrades have been made to the EOSC mainnet, allowing EOSC to continuously evolve towards a decentralized, high-performance smart contract platform, laying the foundation for the large-scale adoption of the crypto economy.

Background

The crypto economy is entering a critical stage, transitioning from social experimentation to large-scale commercialization.

Behind large-scale commercialization lies enormous transaction pressure. For a blockchain system to efficiently handle a massive volume of transactions, it must first provide sufficiently robust performance. To achieve this, higher demands are placed on full nodes, such as better hardware configurations, larger storage capacity, more stable networks, faster bandwidth, lower latency, and so on. Obviously, excessively high full node thresholds will lead to a decrease in the number of block-producing nodes that can operate stably. If a POS mechanism is used in such a blockchain system, the system will quickly converge into a centralized situation.

To strike a balance between high performance and decentralization, the DPOS consensus algorithm is undoubtedly the best choice currently, and it is also the best solution for managing a small number of nodes.

EOSIO, based on the DPOS consensus algorithm, was born, and the community saw a glimmer of hope for large-scale commercialization of the crypto economy for the first time. Whether the election mechanism is fully effective is crucial to the survival of the DPOS consensus mechanism, and it also determines whether the DPOS consensus mechanism can succeed POW and lead the next wave of crypto.

To accelerate the arrival of the era of large-scale commercialization of the crypto economy, the EOSC community has optimized the election mechanism of EOSIO. The EOSC mainnet was launched at genesis block height 1, and continuous iterations and upgrades have been made to the EOSC mainnet, allowing EOSC to continuously evolve towards a decentralized, high-performance smart contract platform.

Consensus Mechanism

EOSC continues to use the consensus mechanism of EOSIO, namely DPOS BFT Pipeline Consensus. Unlike EOSIO, EOSC does not adopt the EOSIO model of one block every 0.5 seconds and one node producing 6 blocks consecutively. In EOSC, there is one block every 3 seconds, and nodes do not produce blocks consecutively. While consecutive block production can reduce the waiting time for unbundled transactions, current network conditions are often not ideal. Fast block production can affect chain stability, resulting in a large number of micro-forks.

EOSIO's current consensus mechanism is not perfect, but as a DApp platform, block confirmation time is not the chain's primary optimization priority. For EOSC, the consensus mechanism must be considered under high load environments. Under the current circumstances where parallel computing mechanisms are not yet perfected, hasty improvements to the pipeline-style confirmation mechanism will lead to significant problems.

The future evolution of the EOSC consensus mechanism will proceed along two parallel paths: 
1. Compatibility with EOSIO, updating its consensus algorithm. Based on the current development progress of EOSIO, we believe that after EOSIO completes parallel improvements, the consensus algorithm will be upgraded, achieving faster block confirmation times.
2. Adaptation of other consensus mechanisms based on confirmation numbers. This will serve as a supplement to the existing DPOS consensus, on the one hand, achieving interaction between embedded Layer 2 chain consensus and the main chain. On the other hand, it can achieve a more decentralized cross-chain mechanism with other consensus chains.

EOSC Technical Improvements

Fee-based Resource Model

While the payment model for CPU and NET resources in EOSIO is a good design technically, it is too complex for users. It also does not encourage DApp developers to optimize their contracts. On the other hand, the way RAM is purchased in EOSIO can lead to hoarding behavior, which is detrimental to the development of the DApp ecosystem. To address this, EOSC has innovatively designed a new resource model, exploring a fee-based resource model in a complex smart contract environment through optimization in practice, fundamentally resolving the resource problems plaguing the EOS ecosystem.

First, EOSC uses a fee model to pay for users' CPU and NET resource consumption. For Actions defined by developers in DApps, DApp developers can set the required fees for Actions. The system uses this to control resource usage for Actions. This approach makes it easier for users to understand resource consumption and strongly encourages DApp developers to optimize contract resource usage, leading to a healthy development of the entire ecosystem.

EOSC adopts a similar approach to renting cloud servers for RAM resource allocation. Users can pay for leased RAM resources through the use of voting dividends. This eliminates concerns about rent payments and prevents rent delinquency. Through a "rent-for-sale" approach, EOSC effectively prevents speculative behavior targeting RAM resources, ensuring that DApp development is not hindered by RAM prices, effectively promoting the construction of the DApp ecosystem.

While boldly exploring new resource models, EOSC is also exploring mechanisms to be compatible with the EOSIO resource model. For CPU and NET resources, users can pay fees based on dividend voting age to achieve a similar effect to EOSIO's staking to obtain CPU and NET resources. For RAM, users can achieve the effect of EOSIO's market-based purchases through a form of staking-for-voting exchange. This allows DApp developers to quickly transition from other EOSIO chains to EOSC and smoothly transition to EOSC's resource model.

Smooth Update Mechanism

EOSC's election mechanism encourages supernodes to actively participate in promoting technology upgrades. Unlike the node version splits in the EOSIO community, EOSC actively promotes technology upgrades and updates in practice.

To achieve a smoother process for incompatible upgrades, EOSC has added an update mechanism based on the effective block height. The community can confirm the effective block height of a function through multi-signature, allowing for a decentralized and smooth upgrade process. Unlike the tag-based scheme for block extension data recently proposed by EOSIO, EOSC's update mechanism is more user-friendly and easier to understand. EOSC was the first to implement decentralized "soft fork" updates on chains based on EOSIO, which is the fundamental guarantee for EOSC's continuous evolution to address various mechanism problems.

On the other hand, the ability to set chain attributes based on multi-signatures provides the community with a decentralized chain configuration on-chain solution. Various parameters and configurations can be decentralizedly modified based on actual development, allowing the community to develop better.

Node Heartbeat Mechanism and Stable Block Interval

To enhance mainnet stability, EOSC has strengthened the construction of candidate nodes from the perspective of the economic model. At the same time, EOSC has added an on-chain node heartbeat mechanism to encourage nodes to improve their stability and promote overall mainnet stability.

Based on the heartbeat mechanism, EOSC can confirm the operating status of nodes, enabling penalties for faulty nodes on the chain, further motivating node construction and preventing node inaction from causing instability in the entire mainnet.

Increasing the block interval time from the beginning helps to avoid occasional soft forks on the mainnet while the current network infrastructure is still not fully developed. The half-second block interval and one-node-producing-six-blocks mechanism designed by EOSIO can indeed improve chain availability in the future, but it is not applicable in the current network environment. With a pragmatic approach, we first increase the block interval time and then switch to faster block production when conditions mature. This effectively reduces soft forks, and the reduced number of blocks significantly improves full node synchronization speed, allowing for more full nodes, thus enhancing the overall network availability.

More Contract Layer APIs

To make it easier for DApp developers to develop contracts, several APIs have been added, and some specific adjustments have been made to system contracts.

First, an API for obtaining block height has been added, allowing developers to efficiently and easily obtain the current block height. Based on this API, contracts can effectively prevent block-blocking attacks and other retry-based attacks. Second, an API for obtaining chain configuration information has been added, allowing developers to adapt various parameter corrections and chain upgrades at the contract layer. In this way, contracts can also seamlessly follow chain upgrade functions. Finally, to prevent fake token attacks, an independent core token contract was used before chain launch, allowing users to clearly distinguish fake token attacks.

Adaptation to Cross-Chain Services

From the beginning, the Yuanli team foresaw that future support for cross-chain functionality would become a fundamental feature of public chains. Therefore, the Yuanli team initiated the development of the Codex project, establishing the Codex.Relay relay chain to provide relay services for various chains, thereby achieving cross-chain mechanisms between different chains. Codex.Relay can be provided with more complete support. By allowing supernodes on two chains to interact with each other, a "complete" cross-chain mechanism can be achieved, where cross-chain processes do not reduce the level of decentralization of any chain.

Through cross-chain mechanisms, significant scalability can be achieved. Based on relay services, Layer 2 subchains can be added. Services and DApps with high resource consumption can run on subchains. Relay services can synchronize the computation results or core status to the main chain. Subsequently, storage, computing, DApp, random number, and other specialized subchains can be added to expand functionality.

Highly Customizable EOSIO Blockchain Development Framework

Based on relay services, Layer 2 subchains can be added. Various subchains will play a significant role in the EOSIO ecosystem in the future. However, it's important to note that currently, developing a blockchain project with customized functions based on EOSIO still presents a high threshold. To address this, the Yuanli team initiated the Codex.io project, a highly customizable EOSIO blockchain development framework, which lowers the development threshold for subchains and provides developers with a more economical and user-friendly subchain development experience. 

The Yuanli team has accumulated a great deal of experience in blockchain development based on EOSIO. The Codex.io project is a "ready-to-use" EOSIO blockchain development framework. Developers can quickly launch their own chains based on Codex.io. After simple configuration, they can customize various symbols, freely choose economic systems and resource models. On this foundation, developers only need to focus on the problems that the chain itself needs to solve, and they can choose to implement them based on contracts or chain native layers. Codex.io facilitates extensions at the native layer of the chain, addressing performance issues while also significantly expanding the chain's functionality.

Codex.io integrates most of the extended functions proposed by current EOSIO chains. With an inclusive attitude, Codex.io allows developers to freely combine on-chain functions: including low-security systems, account systems, various black and white list mechanisms, common governance mechanisms and voting mechanisms, and various plugins.

Through Codex.io, a large number of Layer 2 subchains will be integrated in the future, providing unlimited scalability.