The Road to Lima - an update

It has been some time since the original The Road to Lima post has been published and while it holds still tue, now there are actual dates!

With PR2830 on the node repository we have now two dates for the HF for testnet and mainnet, that would be

  • Wednesday the 16th of October 2019 for Testnet
  • Wednesday the 30th of October 2019 for Mainnet.

The v5.0.0 is almost finalized (rc3 was released yesterday and it looks like no further changes will be needed to became the final release). And the compatible SDKs will be released shortly with support for both Fortuna and Lima protocols and releases.

The new compiler version v4.0.0 is also almost here, with the v4.0.0-rc5 looking promising.

In terms of the API Gateways, the proposed timeline is the following for Testnet:

  • Thursday 10/10 → node update to v5.0.0(-rc3)
  • Wednesday 16/10 → Lima HF

That means that if you reference the API Gateway you will have to update your application befor Thursday the 10th.

For the API Gateway on Mainnet

  • Wednesday 16/10 → node update to v5.0.0
  • Wednesday 30/10 → Lima HF

That means that you will have 2 additional weeks to make sure that your application works with the Lima version.

The nodes behind the Middelware (Aeternal) will follow the same timeline.

For the hosted compiler the default compiler will remain the same (3.2.0) until the Mainnet HF, but the latest version is available at latest.compiler.aepps.com and that is the one it will be required after Lima HF, but more on this later.

So this is a good time to focus on what is changed for the SDKs users and what you should be careful about:

Aens: after the Lima HF it will not be possible to claim names with .test tld, only .aet will be allowed. At the same time, names less then 13 characters long will enter in the auction phase before being successfully claimed (here the documentation, and here the presentation from @michalzee at the aeunvierse conference)

Contracts: it is required to use the compiler v4.x.x after lima HF, the output from the compilers version < v4.0.0 is not accepted by the node. Also, Lima introduces a new and improved VM: FATE (here the FATE specifications and here the talk by @Happi), if you use the SDKs that will be the default vm that is going to be used when compiling/encoding/decoding, that is: FATE is the default VM for the SDKs. If you need to interact with contracts that are already deployed and run with the AEVM than you will have to instruct the compiler client to use the backend AEVM. This applies to generalized account as well.

State Channels: state channel support functionalities are not up to date with the latest improvements and it will be the focus of the next releases iteration.

Follow the aeternityTECH to stay up to date with the SDKs releases.

7 Likes

@noandrea @michalzee:

  • where can we find the documentation for caclulating the required nameFee for claiming the name?

you can use the reference in the erlang code here.

1 Like

And the WIP documentation is here

3 Likes

Is the initial bid price of aens determined?

yes, both the bid price (technically name_fee) and the duration of the auction are a function of the length of the name.
They are expressed in the documentation linked in the OP and by @hanssv.chain and the specific section is this (the link may break when the pr get’s merged)

what is the unit of the name_fee? in the code I see the multiplier is 100000000000000. so if the name_fee is e.g. 5 then this would be 0.0005 AE or am I calculating wrong?

this would mean that the initial price for a name with 12 letters would be 2.8657 AE correct?

I’ve put together a simple script in python:

from aeternity.aens import AEName
from aeternity.utils import format_amount

for i in range(13):
  print(f"name length {i+1}, price {AEName.get_minimum_name_fee('x'*(i+1)+'.aet')} ({format_amount(AEName.get_minimum_name_fee('x'*(i+1)+'.aet'))})")

this is the result:

name length 1, price 570288700000000000000 (570.2887AE)
name length 2, price 352457800000000000000 (352.4578AE)
name length 3, price 217830900000000000000 (217.8309AE)
name length 4, price 134626900000000000000 (134.6269AE)
name length 5, price 83204000000000000000 (83.204AE)
name length 6, price 51422900000000000000 (51.4229AE)
name length 7, price 31781100000000000000 (31.7811AE)
name length 8, price 19641800000000000000 (19.6418AE)
name length 9, price 12139300000000000000 (12.1393AE)
name length 10, price 7502500000000000000 (7.5025AE)
name length 11, price 4636800000000000000 (4.6368AE)
name length 12, price 2865700000000000000 (2.8657AE)
name length 13, price 2865700000000000000 (2.8657AE)

so 2.8657AE looks right

2 Likes

The JS SDK with Lima support is available on npm, here the announcement

2 Likes

the Python SDK with lima support is available on Pypi, here the announcement.

The API Gateway for testnet has been upgraded to v5.0.0-rc.4 as by schedule

1 Like

:exclamation: :exclamation: :exclamation: Important update :exclamation: :exclamation: :exclamation:

Today afternoon there was a last minute change in the aens implementation that was unplanned, the change is about the TLD, it was set to be aet but it was changed late this morning to be chain.

It was decided not to change the dates of the HFs, but of course there wasn’t enough time for the SDKs to test the change and release a compatible version today.

What does it mean in practical terms?

If you are currently not using the aens functionality, then the current Lima compatible versions available can be used without problems.

If you are using aens it means that you will have to upgrade to a newer release of the SDKs that implement the support for the new TLD. We will do our best to release the support for the new TLD in a timely fashion so please follow the aeternityTech to receive the latest updates.

1 Like

can you elaborate a bit more about the reason behind using chain instead of aet?

I don’t know the reasons behind it, maybe @emin.chain or @vlad.chain can help here

I believe it is a purely “cosmetic” change - a more human-friendly extension. Sounds better to me. @emin.chain ?

Since the domain changes have created some chain effect in the availability of all the components needed to successfully upgrade an application, also the proposed schedule for release/deploy of SDKs and hosted infrastructure has changed.

In particular the API Gateway (at sdk-mainnet.aepps.com and mainnet.aeternity.io ) for mainnet will be updated to v5.0.0 on the 28th of October

4 Likes

both Py and Js SDKs have released an update that address the TLD change, Elixir and Go will follow soon

here the announcements:
https://twitter.com/aeternityTECH/status/1184851630300291073

https://twitter.com/aeternityTECH/status/1184849979870982144

Yes, as we only have one domain, most of the front-ends / gui’s will most likely not show any ending at all. Meaning emin.chain will be displayed only as emin in most of the gui’s.

1 Like

Great job, fast fix!

New Elixir SDK version is out with Lima support. You can find the newest version 0.4.0 here.

5 Likes