ENS Improvement Proposal: Platform Source Parameter

🧑‍💻 ENS Development Standards
1

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

Status: draft

Abstract

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.

Specification

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:

require('crypto').randomBytes(32)

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:

  1. Alice refers bob to an ens registrar app using a custom link like app.ens.domains/?referral=AlicentIsAGoodFriend
  2. 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
  3. 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’)

Privacy concerns

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.

Other questions

  • 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.

Updates

  • 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
10 Likes
2

Yea this is a great way to implement this, I like it :+1:

3 Likes
3

Given the limited space available without compromising the security of the secret, why not use a registry of known platforms? That way a single byte can be used for platform ID, and several platform-specific bytes can be used for referral code.

1 Like
4

compromising the security of the secret

The secret is currently more secure than a private key. Even taking 10 bytes out of it, an attacker would need to mine the other information and is unlikely to be able to do it before the secret expires in a week, and even harder to do it until the person reveals it, often in a minute or so.

why not use a registry of known platforms?
We could do both: since we would not enforcing the hash, nothing prevents someone from picking just 0001.

But having a permission less registry could be very useful to tie the name towards an ens name. So the way it could be done would be: get the first 6 letters of the name hash and check if it’s in usage. If it is, then increase it by 1 until you find an empty slot. It could either be done by a common database or directly on chain in a new contract.

1 Like
5

Private keys are 256 bits, the same as the secret.

Sure, but why use more of it than you have to?

This would still require a registry, though - as would any kind of processing on registration data to attribute it to different apps.

6

Given an attacker would have to brute force a hash within the time window of the commitment and the registration (which is I’m willing to bet usually within minutes, but maxes out at 7 days), losing 10 bytes on the pre-image seems pretty low-risk in context, doesn’t it? We still have the public key in the pre-image too.

I’m not sure striving to maintain maximum entropy in this scenario is worth the additional complexity of maintaining a central registry, tbh. Also, if there were ever a scenario in which this actually became an issue, (I mean I think at that point we’d likely be up against quantum computers in which case 10 bytes ain’t gunna save us, correct me if I’m off) we could just tell clients to remove those prepended bytes. No protocol level change, after all.

2 Likes
7

While chatting @gregskril he thought it would cool to separate ensfairy.xyz from ensfairy telegram bot. With more characters this type of hierarchy is possible.

8

Let’s say we put 6-12 chars towards this: 6 for the platform another 6 for the internal code. That would be 48bits, reducing the secret to 208bits, which is still stronger than a 12 word mnemonic. And those are completely optional! If the user wants they can simply not pass on the extra data nor the platform code.

The number is still strong enough that if randomly assigned it would mean that it would take at least 1800 different platform codes existing before there was a 10% chance of a collision. I would say that when we get there, then we could start a registry.

Of course, a malicious entity could mine an account easily to purposefully match any platform code. But the purpose here is to make a leaderboard, not automated payments. If we later use the leaderboard to give out retroactive grants to the top platforms, then I would expect the stewards to exercise some basic due diligence and social consensus to figure out which accounts to send to.

I see it as a soft work that requires few changes and allows a lot of flexibility with very few downsides.

1 Like
9

Updated the following

2 Likes
10

But none of that changes the fact that someone will still have to maintain a registry for this to be useful, right?

11

Yea, that’s a fair point

12

Would such a registry have a use case to be made with subdomains? Something like:
1b7f8b.platformregistry.eth

Issuance of subs would in essence create a registry. Subdomain records would point to their receiving address, and they could set an avatar as well for their platform.

The platform could then issue/maintain their own referral codes, using a 4LD child subdomain schema and using a custom resolver.

As an example this name would contain both the platform code and the referral code within it:
612c63.1b7f8b.platformregistry.eth

Issuance of 3LD platform subdomains could rely on DNS imported names of that platform as some sort of verifiable requirement for issuing a platform code/sub. There’s still some human management involved, but not all the way down to the referral code level, or having to maintain some centralized registry server. It’s just subdomain issuance.

2 Likes
13

Yes, but it doesn’t need to be a hard consensus, just a weak social consensus registry. Like it was done with the 8byte registry: anyone can add or maintain the registry however they see fit.

I don’t think that’s necessary. We’re talking about a probably dozen or so platform codes in the beginning.

1 Like
14

I’m going to reheat this discussion by moving it to ENSIP status with the feedback given

2 Likes
15

New thread here: ENSIP On Chain Source Parameter

1 Like