On February 27th, 2019, æternity 2.0.0 was released and it set the height of the Minerva hard fork to block 47800. We approximate that this block will be mined on March 6th, at 1 PM CET.
The primary purpose of the Minerva hard fork is to add all tokens migrated during Phase 1 of AE Token Migration to the Mainnet. The tokens transferred afterward will be included in the next scheduled hard fork, occurring after the end of Phase 2 in May 2019.
Additionally, this protocol upgrade has allowed us to introduce a number of consensus-breaking features. A detailed overview of the consensus-breaking changes included in Minerva can be found in the release notes for the release candidate and in the notes for Minerva 2.0.0.
The primary changes are:
- setting the minimum gas price on the protocol level to 1000000 in order to make transactions more reasonably priced;
- setting the default gas price in the æternity node to 1000000000 in order to make transactions more reasonably priced. Miners can modify the default value in accordance with their preferences;
- adding an Optional Info field to the key block/header to allow tracking propagation of node updates in the network;
- introducing a new AEVM version containing consensus breaking changes and optimizations;
- adding generic hash functions to Sophia;
Crypto.ecverifyprimitive operation which performs verification of the validity of a cryptographic signature in a smart contract;
- adding bytecode instructions for bit shift (SHL, SHR, and SAR) to VM_AEVM_SOPHIA_2;
- changing AEVM semantics of arithmetic operations to fail on over/underflow.
We have also adjusted the way consensus-breaking changes are introduced into the code. Previously, all such features were merged into a separate
minerva branch, while maintenance of the current release was performed in
master. Creating a release for the hard fork required for those two branches developed separately over the last few months to be merged.
Obviously, this was quite a tedious process. Therefore, it has been decided that from now on, all new features will be merged into
master with consensus-breaking features being guarded by a block height-determined condition. Thus, it will be preventing them from being executed until the next hard fork takes place.
Currently, we do not know the exact height of the Fortuna hard fork, so we are temporarily using a large height range. We will specify the block height as we get closer to the hard fork date.
Additionally, we moved back to a single Pivotal Tracker for tracking the progress of development —æternity Core Dev. All Fortuna-relevant features are labeled with
fortuna to make it easier to distinguish which features will instantly go live, and which ones would have to wait until after the hard fork.
Get in touch: