[Active] Wrapping AENS names into AEX-141 NFTs

aeternity Foundation Grant Applications
44

Update

  • completed all important tests, also the abort cases
  • finished the implementation of the contract logic
  • note: a migration path for Ceres is not considered yet, I am in contact with @hanssv.chain regarding that
  • added scripts to unwrap a name and to burn the nft
  • a new deployment of the contract is now available here:

before I will tackle the migration path, I want to provide scripts to interact with most important entrypoints.

also, I will work on a simple UI to allow using the contract from Superhero Wallet. the plan is that the UI also consumes contract events from the middleware in order to show as much meaningful information as possible about the contract :slight_smile:

in the meantime I encourage everybody to play around with the contract on testnet. additionally it would be great if some eyes could have a look at the source code and check if sth. needs to be fixed / improved:

feel free to just open a GH issue here:

3 Likes
45

Week 28 (Jul 10 - Jul 16)

Time spent: 14.50h

3 Likes
46

Week 29 (Jul 17 - Jul 23)

Started to implement a basic UI and reported bugs / missing features. Following enhancement is highly desired and afaik @davidyuk is working on it now:

New commits:

I also have some uncommited stuff locally.

Deployment of the UI is available here:

Unfortunately we need to be able to sign delegation signatures with an active wallet connection in order to allow wrapping AENS names via UI. I can prepare some stuff but most likely I will switch focus to prepare the contracts for Ceres hardfork. Not sure yet.

Time spent: 15.00h

3 Likes
47

Week 30 (Jul 24 - Jul 30)

I started testing the new SDK version for delegation signature creation. Unfortunately there is still work to be done in the SH wallet in order to make the functionality available for the “average user”. I will continue to prepare the basic UI and look into a possible Ceres migration this week.

Time spent: 5.50h

2 Likes
48

today I deployed another instance of the contract here:

I want to make reward mechanism better testable and decided to deploy another instance of the contract with a max TTL of 3360 keyblocks. the regular max TTL is 180_000 keyblocks which means we’d have to wait quite some some time depending on the config of a specific user. 3600 keyblocks reflects ~ 1 week.

I share this here because I am curious of somebody will be able to grab the reward once the reward block window I have configured kicks in.

otherwise I will just test myself :stuck_out_tongue:

I will probably also create another 1-2 NFTs to test this.

do you guys think that it should be possible for the NFT owner to reward himself by extending his own names??? :thinking: doesn’t really make sense to me, but I am not sure if we should prevent it.

image
image827×757 32.2 KB

4 Likes
49

I guess one should be able to reward themselves if they wanted to :sweat_smile:

Would users always need to wait 1 week for the reward or is this just now for testing purposes?

50

no, so generally it is always possible to extend all names that are wrapped in an NFT. it is up to each user to define if and in what block-window they allow others to receive a reward for extending the names included in an NFT.

of course the reward can only be paid if the user deposited AE to the contract. otherwise, even if defined, the reward for extending names will be zero.

in the example of the screenshot the name would expire in 3313 keyblocks, the regular reward block window would kick in once 960 keyblocks are left until expiration. if somebody extends the names between 960-481 remaining keyblocks, they would receive 2 AE for doing that. for extending between 1-480 block window, the user would receive 5 AE for extending the names :wink:

note:

  • if you want to wrap AENS names right now into NFTs using the hosted application, it currently doesn’t work with SH wallet because of the missing delegation signature support which will hopefully be added to SH wallet :soon:
  • on aeScan you can see that the contract currently has an AE balance of 21 which is the amount of AE I deposited into the contract. the contract also provides an entrypoint that returns the total reward distributed for extending names across all NFTs :slight_smile:
1 Like
51

So there is a higher reward for extending names that are soon about to expire. Hopefully this way most AENS names will never expire again if the owners wrap them as NFTs and volunteers pick the NFTs with the highest reward opportunities :thinking:

1 Like
52

it depends on the configuration and AE deposit of the NFT owners :wink:

I can also decide to provide a higher reward for people that extend “earlier” :sweat_smile: and a lower reward in case of “emergency”.

there could also be zero reward for extending names wrapped in the NFTs. of course community could also extend for free :grin:

1 Like
53

it is also possible to define a specific NFT config which will “overwrite” the global defined user config. in case of an NFT transfer, the NFT specific will be removed.

this feature might be interesting in case people put some of their “unicorn names” into a NFT that they value much higher than others. so they could provide a higher reward for this specific NFT compared to others.

but in any case, AE needs to be deposited into the reward pool of the contract.

1 Like
54

Week 31 (Jul 31 - Aug 6)

Added possibility to set a global config via UI and to deposit/withdraw to/from reward pool in contract

Started experimenting with Ceres features, a branch with first experiments meanwhile exists here:

Independent of that I had a conversation with @michele about a possible integration of the AENS wrapping in aeScan where we identified an issue with using the AENSWrapping contract without caring about case sensitives AENS names which has already been fixed this week by making sure, that the contract internally handles the AENS names always in lower-case.

I also opened following issue in the SH wallet which is kind of a blocker for adoption by regular users, because they cannot use SH wallet to wrap their AENS names right now:

The previous issues reported to SDK in that regard have already been solved by @davidyuk and are included in the latest release v13.2.1.

I proposed new issues and bumped old issues to improve AENS handling in SH wallet:

This week I will continue to prepare the Ceres contract and introduce an easy way to migrate NFTs from the current contract to the future Ceres contract.

Time spent: 14h

1 Like
55

I just extended all names included in NFT with ID 1 on testnet

image
image1438×790 53 KB

this is the tx on aeScan:

image
image1224×557 39.7 KB

as you can see I got a reward of 5 AE for extending the names wrapped in the NFT :slight_smile:

there are still NFT 2 and NFT 3 left to extend for a reward if you want to test:

you just need a SH wallet. extending names is not affected by the delegation signature blocker which is required to wrap names.

note: sometime the UI displays “NFT does not exist” even if it exists. one or multiple reloads of the page should show the NFT details. the NFTs with ID 1,2 and 3 definitely exist! :wink:

1 Like
56

Week 32 (Aug 7 - Aug 13)

I fixed the previously described issue with case sensitive AENS names so that the contract internally handles all AENS names lowercase:

reported a bug that produced bad_calldata when sorting needs to be handled correctly by calldata-lib:

the issue has already been fixed by @dincho.chain but needs to be included in a new release of the calldata-lib. this also requires a new release of the js-sdk afterwards by @davidyuk

I requested a feature to enable the verification of a global AENS delegation signature within a Sophia contract which currently is not possible. this is relevant for the Ceres contract I am preparing:

the feature has already been implemented by @hanssv.chain, but the PR is still open :slight_smile:

I will continue to prepare the Ceres contract which allows to provide a smooth migration to a more simplified contract.

for the enduser stuff and actual testing by users we need to wait for the required features to be incorporated into SH wallet as mentioned in earlier posts.

Time spent: 6.50h

2 Likes
57

Hi Marco! :wave:

In case it would have breaking changes (a major release), otherwise aepps can update calldata by themself in package-lock.json

2 Likes
58

good point! :+1:

59

Week 33 (Aug 14 - Aug 20)

I received some feedback of @hanssv.chain which I incorporated in the current implementation:

Time spent: 1.50h

1 Like
60

Week 34 (Aug 21 - Aug 27)

I updated the documentation of the project and started to prepare the migration from Iris (protocol v5) to Ceres (protocol v6).

The migration path required me to do some custom builds for the Sophia compiler and the aeternity node that enabled new features.

I also identified an issue in my contracts. The latest compiler version now includes a fix that has been introduced with the following PR: Unify typesigs when implementing interface funs by ghallak · Pull Request #469 · aeternity/aesophia · GitHub.

My contract actually used this “bad behavior” and I needed to define a separate namespace to correctly reference the types in the contracts.

Time spent: 18.00h

1 Like
61

Week 35 (Aug 28 - Sep 3)

I finished the migration path from Iris (protocol v5) to Ceres (protocol v6) and I lowered the name limit from 100 to 50 AENS names per NFT due to the following issue: Ceres (v6) gas consumption much higher than on Iris (v5) · Issue #4197 · aeternity/aeternity · GitHub

Commits:

I also identified a strange behavior in the devmode when playing around with protocol upgrades and rollbacks, see `utils.rollbackHeight` rolls back to wrong height · Issue #493 · aeternity/aeproject · GitHub.

The updated contract has been compiled with the latest Sophia compiler release and is deployed here:

Time spent: 15.25h

Final statement

I am very happy about the final state of the contracts and that I even achieved to provide a migration path to a future Ceres contract which will simplify the contract interaction A LOT thanks to the “global” delegation signature that allows the contract to control all AENS names of a specific user.

Huge thanks to @hanssv.chain, who was very helpful along my journey. I am actually awaiting final feedback from him about my contracts before I perform the deployment on mainnet (will let you guys know when that happened).

I also managed to provide a very basic UI that could generally be used to play around with the contract on testnet. Unfortunately it is more or less “useless” at this point because Superhero Wallet misses an important feature to allow aepps proposing the user to sign a delegation signature, see support for signing of delegation signatures · Issue #2222 · aeternity/superhero-wallet · GitHub. As soon as this is possible, I will inform everybody here and provide a mainnet deployment for the UI. (cc @paolo :slight_smile: )

The UI can be accessed here: https://aens-nfts.vercel.app/

For the moment I consider my work as done and I hope to see it wildly used as soon as the Superhero Wallet supports signing of delegation signatures. And of course I would love to see the AENS wrapping integrated into æScan :pray: (cc @michele :slight_smile: )

From my perspective I now finished phase 2 and consumed the approved 200h budget. This means I have to discuss with the æternity crypto foundation how to further proceed with this project. (cc @lydia :slight_smile: )

5 Likes
62

If you like the work and you wanna support me, feel free to send some Æ coins to:

Thanks! :heart:

1 Like
63

Alright, after identifying another important obstacle in regards to bytecode verification (see same compiler version produces different bytecode output · Issue #485 · aeternity/aesophia · GitHub), I finally deployed the contracts in their “final” Iris version on testnet and mainnet.

both contracts have been compiled with the latest Sophia compiler v7.4.0 where the issue with non-deterministic bytecode results has been fixed already, see Release v7.4.0 · aeternity/aesophia · GitHub

you can access my basic UI for both contracts here:

once again, for the UI to be actually usable for wrapping AENS names, we need the following feature available in SH wallet:

more experienced users can take a look at the scripts included in the repository in order to interact with the contract and actually wrap AENS names already before the feature in SH wallet is available.

have fun! :slight_smile:

4 Likes