Dec 20, 2021
Mandel to takeover EOSIO in 2022
The EOS network has not had a major upgrade since the release of EOSIO 2.0 over two years ago. Since that time block.one has produced EOSIO 2.1 and a release candidate for EOSIO 2.2; however, for various reasons the Clarionos team and the broader EOS community do not want all of the code bundled with the more recent releases.
Going forward, the Clarionos team will fork the EOSIO code repository into a new codebase which we have dubbed Mandel (short for Mandelbrot). The Mandel name is a placeholder until a broader consensus among all EOSIO powered blockchains can be reached.
The first version of Mandel will be 3.0 and will be derived from EOSIO 2.0 while cherry-picking some of the most valuable enhancements from EOSIO 2.1 and a few from EOSIO 2.2. Mandel 3.0 will also introduce two new hard-forks: Contract Pays, Enhanced Configurable Blockchain Params. Furthermore, it will cherry-pick the Configurable WASM Limits hard-fork from EOSIO 2.1.
While the EOS block producers have largely remained on EOSIO 2.0, some of the EOS infrastructure nodes and other downstream software have upgraded to EOSIO 2.1. Asking these nodes to “downgrade” to EOSIO 2.0 before migrating to Mandel 3.0 may cause an unnecessary short-term burden; therefore, Clairionos will also make a release of Mandel 2.3 derived from EOSIO 2.1 which cherry-picks support for the new hard-forks enabled by Mandel 3.0. EOSIO 2.1 nodes should be able to seamlessly upgrade to Mandel 2.3 while staying in sync with the network.
Clarionos will aim to migrate as many of the EOSIO 2.1 enhancements to Mandel 3.0 as possible without delaying the delivery of critical hard forks.
Upcoming Hard-Fork Features
- Configurable WASM Limits
This hard fork allows the block producers to increase the size of the smart contracts that can be deployed which will allow larger, more powerful, contracts to be deployed. For security purposes, EOSIO has to limit various wasm parameters such as memory, number of functions, etc. Once a contract hits one of these limits it developers are forced to divide their code across multiple contracts. The original limits were established long before EOSVM gave EOS a huge performance boost. We now feel it is safe it increase these limits. Instead of doing a one-time increase, we have made them configurable. This gives the network the power to expand in the future or to adjust them in the event attackers exploit the extra capacity in some way.
2. Contract Pays
One of the most challenging things developers face is making their applications easy to use. Requiring users to lease CPU, NET, and RAM resources from the network in order to interact with applications is a major usability hurdle. In an ideal world, the smart contract would pay for all of the resources required by the users of the contract.
EOS, as it exists today, requires every transaction to be signed by at least one key and every permission level to have at least a threshold of 1. This limits the potential for contracts to procure the resources needed by their users.
We have developed a method for Contract Pays that doesn’t require a hard fork, but the “hack” involves publishing a “private” key that anyone can sign with. This creates an unnecessary burden for the network when we could simply allow the same transaction to occur without any keys signing it.
An example of an action that could occur without any keys is one where a contract needs to do some maintenance tasks. The contract is willing to pay for its own maintenance and it doesn’t care who authorizes the transaction. If there is no maintenance to perform then the contract would simply reject the transaction and avoid any resource usage. An example of a maintenance task could be many of the tasks currently carried out by the deprecated deferred transactions.
With contract pays it will be possible to implement transactions that are structured identically to Bitcoin transactions. This eliminates the account creation costs for those who just want to use EOS as a currency. It will also make it possible to implement privacy tokens without having your privacy compromised by the resource system. While these things will be made possible by Contract Pays, they are outside the scope of the current roadmap.
More information about Contract Pays is available here.
3. Enhanced Configurable Blockchain Params
This hard fork feature makes it easier to add/remove/configure future objective features. Instead of having to add a new native intrinsic for every new feature or configurable parameter, there is a single intrinsic that contracts can call. This allows contracts to make conditional actions based upon the presence of a feature or the value of a configured parameter. This feature is largely implemented in EOSIO 2.1, yet after review, the Clarionos team has concluded it needs a small tweak to ensure more consistent operation.
System Contract Upgrades
The Clarionos team has a pull request for the EOS System Contact that will enable Contract Pays feature via publishing a “private key”. This will allow applications to develop enhanced user experiences while waiting for the hard fork to take effect. It is also necessary to take advantage of the feature after the hard fork.
Timeline
The following timeline is aspirational and subject to change as development indicates.
January 31, 2022 — Release Candidate of Mandel 3.0
February 2022 — Mandel 3.0 Test Network launched and community validation
March 1, 2022 — Final Release of Mandel 3.0
March 2, 2022 — Network deploys Contract Pays system contract
April 1, 2022 — Mandel 2.3 Released
April 9, 2022 — Next Eden Election
May 19, 2022 — Hard forks activated. (Golden Ratio divide of the year 2022)
This will mark the symbolic completion of EOS independence from block.one because it will be the first time the EOS network is running a version of the software not developed or released by block.one.
Funding
EOS Network Foundation has reached an agreement (pending block producer approval) with Clarionos to pay 200,000 EOS to Clarionos upon the delivery of the Mandel 3.0 Release Candidate (Jan 31, 2022). Clarionos will then support the community with fixes for any bugs discovered during the testing phase.
Future Direction
This roadmap is the shortest path to EOS independence and is the first step on a multi-year plan to revitalize EOS. Some of the items that you will see on the next roadmap update include: 3-second finality, intrinsics to accelerate EVM support, and intrinsic functions to accelerate privacy applications.
EOS is about to accelerate the rate of development like it hasn’t seen in years.
