LONDON (Bywire News) - With a new year, EOS is getting a new codebase in a move that Dan Larimer describes as marking the ‘symbolic completion of EOS independence from Block.one.’ It will mean that for the first time, the EOS network is running a version of the software not developed by its creators B1.
Introducing Mandel 3.0
It’s been two years since the last major upgrade to EOS, with the arrival of EOS 2.0. Since then, we’ve had the release of 2.1 and a candidate for 2.2. Going forward, though, Larimer says it will fork the EOSIO code into a new codebase which they have dubbed Mandel.
The first version will be dubbed 3.0 and will be derived from EOSIO 2.0 while cherry-picking some of the best enhancements from 2.1 and 2.2. It will also introduce two new hard forks: contract pays and enhanced configurable blockchain programs. In addition, he says, it will cherry-pick the Configurable WASM Limits hard fork from EOSIO 2.1.
The release will also come with two other versions – Mandel 2.3 derived from EOSIO 2.1 which cherry-picks support for the new hard forks enabled by Mandel 3.0. This is, he says, to minimise the disruption involved for those infrastructure nodes and other downstream software which had upgraded to EOSIO 2.1.
This will avoid the necessity of having to downgrade to EIOSIO 2.0 before migrating up to Mandel 3.0. Meanwhile, he says the Clarionos team will aim to configure as many of the EOSIO 2.1 enhancements for Mandel 3.0 as possible without delay to the critical elements of a hard fork.
Funding will come from the EOS Network Foundation (ENF) which, pending block producer approval has agreed to pay 200,000 EOS to Clarionos upon the delivery of the Mandel Release Candidate on January 31. Clarionos will then support the community with fixes for any bugs discovered during this phase.
Among the features of the hard fork are:
Configurable WASM Limits: To allow block producers to deploy larger, more powerful, smart contracts. For security purposes, EIOSO limits various WASM parameters such as memory and function. They say that it is now safe to raise these limits to boost performance. Rather than a one-time increase, they have made them configurable giving the network the power to expand in the future or react attackers try to exploit this extra capacity.
Contract pays: Ease of use is one of the biggest challenges for developers when making applications. Users have to lease CPU, NET and RAM resources from the network to interact with the applications. Ideally, the smart contract would pay for all the resources needed by the contract users. As it exists today EOS requires every transaction to be signed by at least one key and every permission level to have at least a threshold of one. As a result, the potential for contracts to produce the resources needed by their users is limited. Larimer says the Clarionos team has developed a method for contract Pays that doesn’t require a hard fork. However, to do this they have to publish a private key with which anyone can sign with. This, he believes, creates an unnecessary burden for the network when they could just allow the same transaction to occur without any keys.
By removing the need for keys eliminates the account creation costs for those who just want to use EOS as a currency and allows them to implement privacy tokens without having privacy compromised by the resource system. These are within the ability of the contract pays but are, they say, outside the scope of the current roadmap.
Enhanced configurable blockchain programs: This feature makes it easier to add, remove or configure future objective features. Rather than having to add a new native intrinsic for every feature or configurable parameter, there is a single intrinsic for contracts to call. This allows them to make conditional actions based on a feature or value of a configured parameter. This is currently available on EOSIO 2.1 but after review, they have concluded it needs a small tweak for a more consistent operation.
System contract upgrades: A pull request is in place for the EOS System contact which will enable the contract pays feature via publishing a private key. This will allow apps to develop enhanced user experiences while waiting for the hard fork to take effect. The feature will also be necessary after the hard fork.
The current timeline is aspirational but runs as follows
- January 31: Release candidate of Mandel 3.0.
- February 2022: Launch of the Mandel 3.0 Test Network and community validation.
- March 1, 2022: Final Release of Mandel 3.0.
- March 2, 2022: Network deploys Contract Pays system contract.
- April 1, 2022: Release of Mandel 2.3.
- April 9, 2022: Next Eden Election.
- May 19, 2022: Hard forks activated. (Golden Ratio divide of the year 2022).
The move represents the next phase of development after the highly public split with B1. After the block producers voted to end payments of vesting tokens to B1, moves have been underway to demonstrate that EOS can successfully pilot a course towards independence. This will play an important role in shaping what the post B1 EOS ecosystem will look like.
(Written by Tom Cropper, edited by Klaudia Fior)