ETHRegisterControllerV2
A brief resume of features Blockful did for ENS
Intro
This present article will cite the more relevant modifications embracing the features voted by the ENS community. The full technical article can be found here and the gas tests here.
Embracing the features voted by the ENS community and demonstrating the gas savings of up to 40% per registration and 75% per renewal in relation to the current method.
Features Implemented
Referral
This feature aims at giving power to registrar apps and influencers as the protocol will share its service fees with the referrer.
Front-end apps can be built to prospect the ENS services in their own domain. An increase in engagement and more elaborated gamification of the protocol is expected.
Commit with Payment
Currently, the ENS app requires two transactions, the first being a plain commitment and the second a reveal where the user sends funds.
By now, a commitment has a minimal waiting period of 1 minute and maximum expiry date of 1 week, meaning that the user could commit to one name and only send the transaction a few days later, but this is not recommended as the name is only registered on the last step, taking 4 steps for the payment to happen. We changed the process so that users could pay first and have their names revealed later by the front-end app.
In the following diagram we can see how those interactions (referral + commit with payment) occur on-chain:
Batch Commit
Since in the last feature we added the option to pay in the commitment and the referral system, we expect single transactions to be more expensive due to storage use and more checks, but with the batch feature, we made the overall cost of multiple names a cheaper process.
Batch Reveal
This feature aims to reveal an entire batch of names at once. It will consume the commit creator's credits on the contract or use msg.value to reveal the batch, in case it meets all criteria.
We made this feature in a way where batches are the intention to register multiple names, containing multiple registrations residing in an array. Even 1 name, is an array with length 1, and so on.
Batch Renew
We found that renewals could also be done in batch, thus we tested the efficiency of it finding out that renewing a batch of 100 names will save up to 74% gas in a single transaction instead of running the same function 100 times.
Contracts Modifications
Organizing the core functions of the protocol, we implemented an interface(solidity’s struct), that will become a more elegant way of managing the registrations in batches:
Every registration holds enough information to guarantee the purchase of names and services. This allows the contract to loop the batch, registering all names in it. Since the consumeCommitment is now called only once in multiple names registered, the gas consumption is reduced for batch name reveals.
We registered 190 names and measured the gas uses for the commits, reveals, and renews comparing the current batch (v2) approach.
We first realize that there is a massive saving with the commit operation itself since the number of times this would be called would change from 190 to 1. Reducing the gas cost of the commits from 8398190 to 44201. If you notice, this will save around 99% of the current cost.
Now jumping to the reveal function which is the last step before firming the registration, we’ve managed to total 262705 of average gas cost for simple reveals including all the new features, this is an increase of around 12% for single registrations.
Although the first name might have a cost increase, the batch mechanism slightly reduces each subsequent name revealed, rapidly finding a plateau at around 40% discount for each name. After 10 names, the discount on new registrations would be reduced by 36%.
We can see in the chart below, the economy when registering batches in relation to a single registration:
Notice how fast the batch registration pushes up the discount on a small number of names. While slightly decreasing the discount on the next name and so on. Every new batch unity is cheaper than the previous as it is showed below:
What amazed us the most was the batch renewal. By doing the same 190 names renews we plotted the same chart doing a comparison between the single renew with the referrer feature and the batch renew:
At the 200' name, the cost for each subsequent name will be a 75% discount. Reducing the usage of a single renewal from 84921 to 21780.
Following is the cost of each unity across renewals:
If you want to check all the test data, more charts, or contribute, google sheets are available here to read and comment on.
Conclusion
Overall speaking about the project: We saw a fascinating growing space for the ENS ecosystem, it feels that getting to know and work with all the mechanics in the contract somehow told us a story about the mission we are helping to build.
Follow us and learn more!
And thanks Gui Neves for your effort on this contribution too!
