EIP registries

[Arachnid]

Some EIPs require registries - lists of mappings relevant to the EIP. Examples include EIP 191 and EIP 634.

Currently, there's no good solution for this: changes to an EIP are prohibited after it's final, so the registry can't be kept inside the EIP itself, and external links are likewise prohibited, so the registry can't be kept elsewhere.

The IETF maintains a list of registries; each RFC can define one or more new named registries, and the registries are maintained separately from the (final) RFC. We should define a best practice for this with EIPs.

[Arachnid]

Tagging @MicahZoltu as the chief no-external-links agitator. :)

[MicahZoltu]

The problem I would want to see solved is determining who has control over the registry. If we just want to give control to some operator (or group of operators) things are simple, but for a censorship resistant/decentralized registry things suddenly become way more complicated.

A while back someone built a censorship resistant registry called ENS which did a pretty good job of protecting itself from future censorship and capture, could we just use that system? e.g., allow people to point at an on-chain registry from their EIPs and leave it up to on-chain contracts for access control.

I would really rather avoid re-building something like ENS for every list, and I'm not a fan of EIPs that just point at some censorable/closed registry, as that feels like it goes against the ethos of Ethereum to me.

[Arachnid]

If we just want to give control to some operator (or group of operators) things are simple

This is pretty much how EIPs work; I don't see a problem with replicating this for registries.

A while back someone built a censorship resistant registry called ENS which did a pretty good job of protecting itself from future censorship and capture, could we just use that system? e.g., allow people to point at an on-chain registry from their EIPs and leave it up to on-chain contracts for access control.

I don't think there's any reason to have this onchain - and doing so doesn't really solve any issues that using Git doesn't.

[MicahZoltu]

TL;DR: Registries don't have the same trust/censorship resistance properties as standards because they are mutable after introduction into production systems.

When used appropriately, EIPs should not be implemented by anyone in production until they reach final, and once they are final they should not be mutated. Lists on the other hand do not follow this pattern as they are continually mutated even after they have reached a final state.

Unlike final EIPs, a registry EIP is subject to censorship or other author malfeasance at any point in the future, after it has reached production systems. For example, the author could decide not to include competitor product X in the registry after people have already asserted that their registry is REGISTRY-Y compatible and those implementors may have setup an automated system for maintaining synchronization with the registry.

Someone could, of course, create a competing registry in this repository that includes everything from REGISTRY-Y but also includes the censored competing product X, but now we don't have a single canonical list and instead we have multiple competing lists covering the same thing.

One can imagine some kind of federated system where anyone can create an EIP that adds an item to a list, and I would be more in favor of this. We could have the EIPs site (in theory) aggregate all registry additions and maybe even have some fancy logic for preventing collision between registry additions. This is a notably bigger effort than just creating registry EIPs though.

[Arachnid]

When used appropriately, EIPs should not be implemented by anyone in production until they reach final, and once they are final they should not be mutated.

I think we both know this isn't true in reality.

Lists on the other hand do not follow this pattern as they are continually mutated even after they have reached a final state.

Registries of this sort are append-only, which I think is meaningfully equivalent to the EIPs repo. An EIP could specify that new entries are added to the registry via new EIPs created in the EIP process, but this would probably be too high overhead.

One can imagine some kind of federated system where anyone can create an EIP that adds an item to a list, and I would be more in favor of this. We could have the EIPs site (in theory) aggregate all registry additions and maybe even have some fancy logic for preventing collision between registry additions. This is a notably bigger effort than just creating registry EIPs though.

I don't think this is a solution to this problem. Either the namespace is small (for example, 8 or 16 bit identifiers), in which case only a single registry is practical, and editorial control is required to portion out the namespace, or it's large (for example, string identifiers or UUIDs) in which case censorship is fairly pointless, and the registry exists to avoid accidental collisions between 'standardised' (as opposed to vendor-specific) keys.

I think you're allowing the perfect to be the enemy of the good here. We don't have some hypothetical best-of-all-worlds decentralised registry system, and if the EIPs process won't allow creating or linking to a more practical registry, any EIP that depends on registries will be varying degrees of broken until then.

[MicahZoltu]

I have been thinking about this and I think I can get on board with using the EIPs repository for it under the condition that a registry EIP (or whatever we call it) MUST:

• include criteria for inclusion in the list
• be append only only (never remove or modify)
• be updated to include any entries that meet the inclusion criteria (regardless of original author agreement)

The list would otherwise be immutable (aside from non-normative changes) like EIPs are.

The goal here is to make it so any lists managed in the EIPs repository brings with it a similar level of censorship resistance and permissionlessness that other final EIPs have.

To deal with the small namespace lists (e.g., 8-16 bit space) it would be recommended to authors to include incredibly strict inclusion requirements, while large namespaces perhaps are more lax.

As for the process of actually appending an item to the list, a PR where the appender makes their case that they meet the requirements seems reasonable to me, but I'm open to some other process.

[Arachnid]

Rather than adding it to the EIPs repo as a new type of EIP, I'd suggest a new repo specifically for registries, that EIPs can reference. Otherwise, agreed.

[github-actions]

There has been no activity on this issue for six months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

There has been no activity on this issue for 1 week. It will be closed after 3 months of inactivity.

[github-actions]

There has been no activity on this issue for 1 week. It will be closed after 3 months of inactivity.

[github-actions]

There has been no activity on this issue for 1 week. It will be closed after 3 months of inactivity.

[github-actions]

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback.