`aeternity` node release v6.3.0

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 :slight_smile:

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 :slight_smile:

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-string was 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.

9 Likes

good job!hope many hyperchain soon!

1 Like

It is up to exchanges to allow deposits and withdrawals, we can only take care of the network to operate smoothly.

3 Likes

Hello sir
When could we sell aens in market?

Mod, please moved unrelated comment from this thread to correct section. @aniputapet.chain @erik.chain

All the protocol needed for transferring of names is already there. You surely can sell names via a smart contract. Unless I am missing something, you have all the functionality needed. If there is something I am missing, please say so and we will plan for implementing it. If you need a market for buying or selling names - this surely is not a core protocol feature and does not belong in this thread :smiley: What we are doing is making the core software better, then anyone can build on top of it.

For example - the combination of all changes we did to the transaction pool leads to much more aggressive approach in cleaning up invalid transactions. The result is visible on the integration nodes on testnet already (with a timescale of 1 month):

image

Those nodes used to have a constant bunch of invalid transactions in their pools. The new approaches clean up the transaction pool from those invalid txs. Now those nodes do have a few transactions in their pools and are much more efficient in handling those. Since the scale of the graph above is so big, it is hard to see the transactions there. So here you go again the size of the transaction pool on the same nodes for the past 4 hours (so a different scale):

image

So they are around two orders of magnitude less transactions in the pool. This means bad actors (publishing invalid transactions) are being punished while good actors are rewarded with faster confirmation times.

7 Likes

very good job;please attention;dimitar just core developer。@dimitar you can tell us
Who can talk with the exchange

1 Like

The release is ready.

Since it is not yet deployed to our nodes, we keep it as a pre-release. The deployment is the last step of the process, once done - we will change the tag of the release. You can upgrade now or wait of the seed nodes to be upgraded. This will happen tomorrow.

6 Likes

It is deployed to all nodes. The release is marked as the latest. Node operators are suggested to upgrade to it in order to take advantage of all the new features. Cheers!

7 Likes