There had been a lot of progress in the node. A few epic refactoring are coming to an end and we are really excited about those. We are preparing a new release. The work on it is almost done, we are merging the last PRs and making some final tests. Unless something pops up, the plan is that we release the new version v6.3.0 on 5th October, Tuesday. If we find an issue, I will inform you 
This release focuses mostly on two areas: Sophia developers tooling and the transaction pool. You can find some details below.
Different modes
We had developed an initial support for a plugin system so other functionalities can be developed as plugins. I will share more details about this next week. The prime test subject for this system is dev-mode - it is a way to set the node in a test mode. This is a feature we are working in tight cooperation with devtools team. This mode uses a special consensus that we usually use in our internal tests. It now allows the node operator to mine on demand. It comes with a special API that would be consumed by a test execution tool. The goal is to provide end-to-end testing environment for Sophia smart contracts. The dev-mode comes batteries included - sensible default values and a simplified config.
The dev-mode is mostly a product of a big refactoring that had been happening for some time now - introduction of different node modes. This allows us to enter the node into different states, disabling whole segments of the software while letting the other parts of the system to continue functioning. The initial goal was having a maintenance mode - a special mode that has the sync and mining subsystems disabled. This allows us to inspect the node’s DB while it is static. This was a prerequisite for the Rosetta API, which now we can start developing. It also allowed us to start developing different scripts, for example the new version of the node comes with a DB rollback script that allows the node operator to revert the system back in time and let it sync again from there. The maintenance modes now also comes in a form of a script:
bin/aeternity maintenance on | off | status
All of this will be part of v6.3.0.
Transaction pool
The transaction pool had been a hot topic for quite a while now. We’ve done some great improvements there but there is some technical debt in that area that we would have to eventually face. At this point we have a couple of different strategies there and we are trying to find the balance between them. Once we do, we would make a big refactoring so we can support it easier, while keeping the proven-to-be-good approaches.
In v6.3.0 we revisited the transaction pool and the micro block generation approach grounds up. Since the goal is getting smoother experience for actual users, the node will now punish bad transactions. The transaction pool now has a strict mode. This allows us to specify different number of retires per transaction error.
Some context: a transaction can be invalid (like - having a plain wrong signature) or temporary invalid (when there is a nonce gap, there might soon arrive a transaction that fills the gap and this transaction will become valid instantly). The outright invalid transactions are not allowed to enter the pool ever, but the temporary ones are allowed in. Then they stay for some time, taking one of the following paths:
- the transaction becomes valid and it is included in a block
- the transaction is garbage collected - this is configurable but by default the transaction stays for 2 weeks
This results in a the transaction pool having too many transactions in the pool for too long. Then they are tried to be valid by the miner once a generation, so this also introduces a computational overhead for miners.
The strict mode takes a more dramatic approach - each node operator can specify how many attempts a temporary invalid transaction is allowed. This is granular down to the error itself - for example if there is a nonce gap - some grace period is provided but if the wrong vm version is being used - the transaction can be kicked out of the tx pool right away. This is all configurable by the node operator in the settings but some sensible defaults are provided.
If a transaction had been tried and it was kicked out of the transaction pool, the old behaviour is to allow it back, in case it could become valid again. v6.3.0 takes the opposite approach - a transaction that was deleted locally is not allowed back in the pool. This is of course configurable and a node operator can choose to allow those in their own pool.
What is more, we revisited the micro block generation approach - this would be even longer to explain but a short version would go something like this: a micro block has a 6mln worth of gas, so far some of the blocks were not consuming it all. We now use a new algorithm that would result in putting more transactions in a single micro block while keeping the 6mln gas limit in place. This will likely result in a higher transaction throughput and we would probably measure it
Other small improvements
We’ve also merged some smaller improvements:
- We revisited the State Channel minimum depth values and provided a new strategy for it
- We fixed a bug that was crashing a few HTTP endpoints when the flag
int-as-stringwas raised - We identified a bug in OTP 21. For quite some time now our releases come build with OTP22 so now the default OTP version is 22. OTP23 is officially supported now. This is a step towards support of OTP24
I guess this is it, stay tuned for the new release.
What we are doing is making the core software better, then anyone can build on top of it.
