Release `aeternity v6.2.0`

We are aiming at delivering regular node releases. What is more, we are putting some effort in better planning of our release cycle. In this light, we announce our plans for Aeternity v6.2.0. We aim at producing the release at week 31 (2-8 August). It will focus mainly on transaction pool improvements:

  • More finely grained garbage collection of transactions in the pool by their reason of not being included. GH issue
  • Introduce a new HTTP endpoint: /accounts/{pubkey}/next-nonce with two different strategies. GH issue
  • Introduce a new debug API: if your transaction seems to be stuck in the mempool, the endpoint will answer you why it is not being included. This does not take into account gas prices. GH link
  • Adds new a group of HTTP endpoints: node-operator. It is to hold endpoints that are meant to provide functionality for thinkering of the node and diving into its internals. Those should be only internal and the group is disabled by default. The new group will be present only in the new OAS3 API and will not be present in the old swagger2 API.
  • Add a new HTTP endpoint: DELETE /node/operator/mempool/hash/{hash}. It deletes a transaction currently present in the mempool. It is a part of the internal node-operator API.
  • Some stability improvements and small bug fixes.
9 Likes

Today is August 7th, 2021. There is still one day before the 8th.

1 Like

where is the version of Aeternity v6.2.0 ???? If you can’t even guarantee the technical progress, you’d better solve the problem about deposit and withdraw of exchange !

1 Like

We are working on it. Onboarding hyperchains nuked our schedule.

1 Like

To a hyperchain? When they are ready, currently there is a closed testnet but there are some missing pieces still. Then comes the heavy testing. I expect some detailed information to be shared soon.

Regarding technical progress - we are doing it, we only lack one feature for the 6.2.0 release and we ship it :slight_smile:

WRT deposits and withdrawals - this is not a technical issue so I can not really help here, the ball is in the exchanges. They are centralised entities that follow their own business model. You can withdraw and deposit in gate.io and Coinw, there are talks to other exchanges as well but this is under NDA.

5 Likes

Don’t be affected by the complaints of a small number of people. I believe most people have patience. We hope that aeternity is safe and efficient. We will wait patiently and support the aeternity team

5 Likes

Thanks, we are doing our best here :slight_smile:

5 Likes

When can we solve the depsoit and withdraw of the exchange??? We can’t see what the team is doing now. from the exchange to the market, nothing is good! it’s so bad !!!

1 Like

2021.8.14 :slightly_smiling_face:

I don’t know your sources, but I am certainly not selling my AE, on the contrary - I am hodling for good. My actual concern is that instead of following a healthy bump, the price can skyrocket and this can hurt its usability. Just look at ETH or BTC - it is insanely expensive to do transactions there.

Regarding release 6.2.0 - I know it is taking more time than expected but it touches some really important internals - the transaction pool’s getting rid of invalid transaction’s strategy. Take this example:

Alice has 10 tokens
Bob has 20 tokens
Carol has 15 tokens

Carol sends Alice 10 tokens out of her 15, so she is left with 5. Alice sees this tx and knows she will soon have 20 tokens - she imeditatly sends 18 out of them to Bob. She issues this to a node, so does Carol but because of network propagation - those txs go through a couple of nodes to reach the miner. They can arrive in any order so if the miner tries applying Alice’s spend transaction before Carols - Alice would have only 10 tokens and she obviously can not spend 18 out of them. Her transaction is invalid but will become valid as soon as Carol’s transaction gets included in a micro block. So we keep Alice’s transaction for a while.

So far we had a global setting “keep for this amount of generations”, no matter how many times this transaction had been tried (and failed!) and why it failed. I am currently rewriting this to provide better granularity for specific errors - for example if you have a name claim transaction that points to a commitment you don’t own - this does not seem like changing anytime soon and there is no point of keeping this transaction in the pool.

The thing is that I am going for each transaction type, error by error, putting sensible default values. Those all will be configurable if the node operator desires so. Some errors happen to be too specific and there will be a little sense keeping them in the config, so there will be a default value for them.

My point is that this is a sensitive part of the code that I’d rather be careful with. If that means more time needed - sure, it is better than pushing something that could hurt the network.

Stay tuned for more updates, I expect the next one to be with a link for the 6.2.0 release :slight_smile:

6 Likes

Is there a way to make sure this is true?

1 Like

Some of the information is sensitive and I can not share a lot but for sure what I can way is that the part for the exchanges is dead wrong - the AF is in talks with exchanges for resuming deposits of AE.

5 Likes

How long have we been talking? When can the deposit and withdrawal be opened?

good job;cheered!But I think your opinion about prices is completely wrong; only prices rise; can attract more users, investors, developers.Again; ae prices rose 100 times; transmission costs are still low

3 Likes

I don’t claim I understand coin economics :smiley: I totally agree that if the coin goes 100 times, the fees would be still low enough not to hurt the ecosystem, but my expectations are higher than x100. Again - I don’t claim to be an economist, just my 2 satoshis.

8 Likes

Thank you and hope to see AE great again!!!

5 Likes

团队没有经济学家吗?不招几个?

1 Like

Great explanations. :sunglasses:
Thank you and my respects.

3 Likes

After some discussions, we released 6.2.0

The strict mode of the transaction pool is not there and will be part of 6.3.0 instead. The reasoning is simple: we would like to deploy it on testnet to see if default values are sensible or they should be adjusted, this will take days. Since the current model is stable and working as expected, this should not be a reason not to release the other features and improvements we had accumulated. For the full list of those, please consult the readme:

The strict mode for the tx pool is simply a subject too delicate to push, sadly I was overoptimistic about its scope. For those of you that are desperate to try it out, we will produce a special fork so you can use it as soon as it gets merged.

Hopefully this adds some transparency of what we are doing and why. Cheers!

4 Likes

cheers!well done!

5 Likes