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!

Blockful | 🐦 | 🐱 | 👤

And thanks Gui Neves for your effort on this contribution too!

ETHRegisterControllerV2 was originally published in Blockful on Medium, where people are continuing the conversation by highlighting and responding to this story.

Earn commission by creating ENS DApps

Intro

The Ethereum Name Service wants to implement a referral program inside its ecosystem, so we did it! Every registration of a new ENS or the renewal of one creates a referrer opportunity. The referral commission is settled by the contract owner and the ‘_setBalance’ function will split the purchase rewarding the same percentage that was previously settled. To disable referral commission, simply change its value to 0 and no rewards will be given.

Implementation

For backward compatibility, we created ETHRegistrarControllerV2 and IETHRegistrarControllerV2 for adding this feature and the next ones we are working on.

No additional imports were needed. Currently using the IETHRegistrarControllerV2 interface.

Variables

referralFee: A variable with type uint256 called ‘referralFee’ should be initialized with any value from 0 to 1000 — for better granularity. Representing the percentage for which the referrer will receive.

uint256 public referralFee = 50;

balances: A mapping variable addressing the uint256 eth value into the referrer address. Storing the information within the contract that allows the referrer to claim that value by calling the ‘withdrawn’ function

mapping(address => uint256) public balances;

Functions

setReferralFee: A set function, for the ‘referralFee’ value, was made to adjust as intended by the protocol. Notice the event emission registering the change as well as the conditionals to assure that the minimum and maximum percentage are possible to be set correctly.

• The function will accept one argument which will only be valid by being an int value between 0 and 1000, otherwise, it will revert.
• Only the contract owner can call the function

_setBalance: This function is supposed to split the eth received after purchase or renewal of an ENS domain, based on the percentage settled in the referralFee variable. It has two inputs:

• address referrer
• uint256 amount

The referrer will have the amount stored in a map in case criteria are met, being eligible to withdraw that amount by calling the ‘withdraw’ function. Otherwise, in case there is no referrer set or the commissions are off, the entire amount will be registered in the name of the current contract owner.

withdraw: A regular and safe approach to withdraw:

This will always, simply empty the user balance registry and transfer that amount back to him, the ‘msg.sender’.

Depending on how this function will be handled by the front-end or in case other contracts want to externally call it, we can save some future trouble on gas waste, by setting a ‘require’ function to avoid registering in the mapping and also trying to call a transaction evaluated in 0 eth.

Interface

Event Emission: The importance of event emission is due to the easy task which is collecting those data externally to generate useful statistics. For this reason, we tried to implement the emit event where the ‘NameRegistered’ and ‘NameRenewed’ are being implemented, facing an issue with the _register function, where it reached a stack-too-deep issue. Remaking the contract's internal architecture to better fit the referrer event within both records above would be the best approach.

Created events to handle referral business: Our turnaround was emitting the event inside the ‘_setBalance’ internal function, thus creating a separated event record named ‘ReferrerReceived’ and ‘ReferralFeeUpdated’, to track the referral usage, adding every successful referral program into the logs. ‘indexed’ is being used to search the logs easily

Changes

The changes that had to be made to the previous version to better fit the referral function.

Functions

register: This function is currently receiving the referrer address as an input from the back-end, being sent straight to the ‘_setBalance’ function after all the requirements have been met. Read concerns in conclusion, about a possible security breach and optimization. The function is called by passing two arguments:

• address referrer
• uint256 totalPrice

_setBalance(referrer, totalPrice);

renewal: The renewal function follows the same behavior as the register. It receives the referrer address, inputting the value on the front-end, and only is used when the function calls ‘_setBalance’ after all the requirements are met.

Interface

Moved events from ETHResitrarControllerV2.sol to IETHRegistrarControllerV2.sol: We realized that the standard for event management in the ENS contracts standard, is to have its initial structure settled inside the interface of the given contract that will emit the event. Although we have a different scenario in the ‘ETHRegistrarControllerV2’, where the structures were previously settled in the main contract, instead of where it is supposed to be, at ‘IETHRegistrarControllerV2’. Thus we moved the event structure.

Extra improvements

Rewriting some tests to TypeScript and adding typechain we found some errors and saw an opportunity for creating a npm package that we used in test improvements, if you are curious, here is the article about it.

BulkRenewal: We found that a test wasn't testing the renewAll function properly, discovering an error in the BulkRenewal.sol.

For renewing a name you should only pay price.base (line 15 from gist above). The renewAll function was calling renew with msg.value being price.base + price.premium, causing the error "Transaction reverted: function selector was not recognized and there’s no fallback nor receive function".

ETHRegisterController (V1): The withdraw test wasn't actually testing the withdraw functionality from the contract.

The state from the local blockchain is being reverted after each test because of these hooks above.

This means before the withdraw function is called, the contract already was with 0 ether, then the except assertion would pass even if the withdraw function wasn't executing as expected.

All corrections are at the Blockful repository

Conclusion

There is a huge opportunity for referrals in the ecosystem. User and protocol working together to boost the protocol functionalities providing more engagement and flourishing the partnership.

Follow us and learn more!

Blockful | 🐦 | 🐱‍👤

Referral Feature added to ENS was originally published in Blockful on Medium, where people are continuing the conversation by highlighting and responding to this story.