This is a draft/heat test for a new standard for prepending the commit secret with a platform source. It’s an attempt to format this earlier post by Slobo.eth into an ENSIP.
Authors: @slobo.eth and Avsa.eth
There are many reasons that we might want to be able to measure how and where users are registering names. One of them is simply by knowing our own ecosystem and which apps are more popular, but it’s also very important to be able to identify the creators who are helping the ecosystem. Retroactive funding via grants is often better than proactive funding because you can detect what has already worked, instead of stewards having to make bets on what they think would happen. Often in this community we are surprised by things becoming popular that we would never be able to predict. On the other hand, it’s important to make the process transparent, open source and privacy preserving.
The ETH Registrar Controller takes as input: name, owner, duration, secret and resolver. The
secret parameter is random data that obscures the name before the final step of the registration process is complete. It is 32 bytes of entropy and the ens manager app on app.ens.domains generates it by calling the following:
This proposal suggests a social convention that generates the secret from a combination of taking the first 6 characters of a namehash, add another 6 characters for extra data and combines it with the appropriate number of random bytes.
This way the first 6 char of the secret would be the platform name and the next 6 would be reserved for internal data for that platform – like its own referral code. So for example if the above was registered via ensfairy the secret would be:
0x 1b7f8b 612c63 3cbcc635528d3b7196bc89d13566c1be2068af0cad6fb3ecebf0
With this we can attribute registrations using the first 12 chars of the secret. The loss of entropy of 48 bytes is not relevant, since the only goal of the secret is to obscure the details of the bid to avoid front-running during the short period (usually a few minutes but it could be as long as a week) before the reveal transaction is executed. The secret still retains 208 bytes which is highly secure, specially for a short time frame.
The extra data could be used in this example:
- Alice refers bob to an ens registrar app using a custom link like app.ens.domains/?referral=AlicentIsAGoodFriend
- If bob clicks that link, that information is saved on the cookies/ local storage, until it’s overwritten by another referral code, bob clears his memory or some time passes and the code expires
- When bob wants to register a name, the secret will be prepended by the first 6 letters of the platform and then the next 6 characters generated by the sha256(‘AlicentIsAGoodFriend’)
This action, by design, makes it public which apps the users are using to register names, and might reveal who they are friends or who they follow. It could review also some demographics of accounts–if a registrar app is known to be very popular in a country or to only have the UI in a language, it can reveal that a specific ethereum address might be from that demographic. This is not unlike seeing a user send funds to a known exchange address.
To alleviate these concerns, we ask app makers to make the process transparent and allow users to opt-out of either the referral code or the whole platform code being added on their secret.
This would also enable to compare different clients usage–again this is by design. If a given platform doesn’t want any of their numbers public, they can simply not implement it.
- Isn’t it possible to add other platform codes in yours? Yes. We don’t see that as a concern, since platforms probably want to maximize their own numbers
- Is this coming with a referral program? No. This is simply about adding the data so we could have a leaderboard. What to do with the data is for another time.
- Does this replace the proposed v2 registrar? No. That contract–if implemented–would be a code change that would allow a trustless referral program, immediate and on-chain. This change would not require any code change and would simply provide the data, requiring steward working groups to then act on it on a later date.
- Can this be done with Google Analytics? Any registrar app can use their own analytics software to analyze their own usage, but this would allow to create a trustless way in which multiple clients could prove their own name usage.
- Changed 10 chars into 12 to add 6 for the platform and 6 extras
- Changed from sha256 of a string to using the beginning of a namehash