ETHRegisterControllerV2 #128
Conversation
https://www.ensgrants.xyz/rounds/1/proposals/16 Some other benefits are the gas savings in these new features as shown here |
|
Outstanding work! I'll give this a more detailed review soon, but I had one initial thought about the tips/referral mechanism that bears thinking about. What if, instead of maintaining a mapping to individual commits for pre-payment, we keep a per-account balance that can be used both to fund registrations and for referral fees? A commit-with-fee can fund this account, and referral fees can be added to the users' balance, while a reveal consumes any balance in the user's account, sending the remainder back to them so they don't have to manage withdrawals. This will require keeping a separate counter of accumulated fees that can be withdrawn to the DAO, but I think it should still work out lower gas-cost than sending the referrer their fee in each TX, and simplifies the UX and the code. |
|
edit: just saw this was posted to the forum stating it will need a full vote still - apologies! https://discuss.ens.domains/t/ens-controller-v2-is-ready-for-code-review/14510 |
|
Awesome stuff! There are a few changes we made post audit, so this will need to be merged into your V2 code as well. One example is: Please have a look at the current .eth controller contract for other additional changes. I will also find some time to take a closer look and give more detailed feedback |
| * @param _referralFee The fee to be used. From 0 to 1000. | ||
| */ | ||
| function setReferralFee(uint256 _referralFee) external onlyOwner { | ||
| require( |
There was a problem hiding this comment.
I'd suggest to use custom errors as opposed to text.
|
@Arachnid "What if, instead of maintaining a mapping to individual commits for pre-payment, we keep a per-account balance that can be used both to fund registrations and for referral fees?" I agree. This is actually something I have disagreed on implementation with @alextnetto. Initially we had agreed to have a general balance for everything: fees, referrals, tips, funds, etc, but in the end the team argued that it was actually more costly in terms of gas to save the new balance than just to send the ether directly. As they were optimizing for gas I let it pass, but I'm still curious about why that would be the case. |
Here is why we send the ether directly |
Did you test this in the case where the accounts already have balances? Setting a storage slot from zero to nonzero costs 20k gas, but changing its value if it's already nonzero costs only 5k. |
|
Heyy friENS, what's missing for getting this for a voting on DAO, can I do something to help, review, modify? |
New Features:
You can read more about all we did in this medium article
Since we changed a lot from the previous version, we created a V2 for the new files
These features will reward front-ends (registrar Dapps), increase domain registration, and enlarge the community, creating third-party services for the ENS ecosystem.
By implementing the referrer as an option in the register and renew functions, the protocol will provide commission when executing the service and share a fee previously settled by the DAO, with the referrer.
Front-end Dapps will be built to profit on the refer share. And furthermore can be done with the payment with commitment, which can incentivize a relation of trust between the final user and front-end Dapp, enabling names to be purchased with a better UX, by a single transaction.
To save even more in gas costs, the batch feature will vastly increase the intention of acquiring new names, since the gas cost will rapidly decay when purchasing more than 1 name.