cryptonewsz.com
Since the introduction of EOSIO 2.0 over a couple of years ago, the EOS network has not been upgraded. Block.one has released EOSIO 2.1 and also introduced the second version, EOSIO 2.2, however the Clarionos team and the larger EOS community do not want all of the code packed with the more recent releases for different reasons.
The Clarionos team is working on forking the EOSIO source repository to a codebase called Mandel in the future (shortened from Mandelbrot). The name Mandel is the placeholder until each of the EOSIO-integrated blockchains reaches a consensus.
Mandel’s initial version, 3.0, is an offshoot of the version EOSIO 2.0, with some of the most useful additions from EOSIO 2.1 and a few enhancements from EOSIO 2.2. There will be two hard-forks introduced in Mandel 3.0: Enhanced Configurable Blockchain Params, and Contract Pays.
Many producers of the EOS block are still using EOSIO 2.0, certain infrastructure of EOS and other downstream applications have migrated towards EOSIO 2.1. Making these nodes “downgrade” to EOSIO 2.0 before moving to Mandel 3.0 may impose an unnecessary short-term strain; as a result, Clarionos is keen on releasing Mandel 2.3, a fork of EOSIO 2.1 supporting new hard-forks provided by Mandel 3.0. EOSIO 2.1 nodes should be able to update to Mandel 2.3 without losing network connectivity.
Future Hard-Fork Features
1) Configurable WASM Limit
The WASM Limit hard fork enables block producers for the expansionof the smart contracts’ size that can be deployed, allowing for larger contracts. EOSIO must limit certain wasm parameters including memory, different functions, and so on for security reasons. Developers are required to distribute codes over many contracts if a contract reaches one of these restrictions. Even before EOSVM boosted the performance of EOS massively, the original limits were set. It is quite safe to raise the limits now, according to the team.
2) Contract Pays
Making programs simple to use is one of the most difficult tasks for developers. To engage with programs, users must lease NET, CPU, and RAM resources from the available set of networks. This is a big usability barrier. In a perfect scenario, the smart contract covers all resources that the contract’s users demand.
3) Enhanced Configurable Blockchain Params
This type of hard fork simplifies the process of adding, removing, and configuring future features of objectives. Instead of adding a new native intrinsic as per the feature, contracts can invoke a single intrinsic. Contracts are able to perform actions according to the presence of the valuable parameter.