Add a `Superseded` status

[xinbenlv]

In RFC, after finalized and adopted, can be declared as superseded by another RFC

I wonder if we want to add superseded-by: (eip number) as a preamble section, and "Superseded" as a status after Final.

If an EIP's spec is completely out of date, and the only value is as a historical reference: implementer of clients / smart contracts shall be pointed at the new EIP number, shall be considered "superseded".

Examples I can think of:

1. an EIP-A specifying a fork at blocknum, and after that fork, the later fork comes up as EIP-B
2. a parameter was specified in EIP-C, later that same parameter was modified again.

Love to hear your thoughts

[xinbenlv]

Example:

https://datatracker.ietf.org/doc/html/rfc822

"Obsoletes:  RFC #733  (NIC #41952)"

[MicahZoltu]

We have discussed superseded in the past and have decided against it. The primary reason (IMO) for not including superseded is that it means someone has to decide which EIPs supersede which. For example, there are dozens of token contracts that are better than ERC-20 and all of them would love to be the "official" token that supersedes ERC-20 and have EIP-20 point at them, but who would make the decision which one is the one that actually supersedes it?

Similarly, what if someone claims to supersede ERC-20 but not everyone agrees that it does and some people think ERC-20 is still the "correct" token contract?

TL;DR: it is a governance nightmare to add superseded-by to an EIP.

We could have a supersedes field on EIPs that points backward, but I feel like that wouldn't add much value and every token would claim to supersede ERC-20 and I fear there would be user confusion because people would assume that when they saw that there was some official process by which a token supersedes another, when really it is just the author saying "you should use this instead of that".

[Pandapip1]

How about the EIP authors decide when to use superseded-by? There is a good use case for it: see https://eips.ethereum.org/EIPS/eip-820 and https://eips.ethereum.org/EIPS/eip-1820.

[xinbenlv]

How about the EIP authors decide when to use superseded-by? There is a good use case for it: see https://eips.ethereum.org/EIPS/eip-820 and https://eips.ethereum.org/EIPS/eip-1820.

I totally agree with @Pandapip1 on this. I think it should be only fit that the original author(s) to decide whether to move an EIP to superseded and add superseded-by.

Another use case is that the original author can now make new proposal as their new recommended version. Other-wise, there seems no good way for readers of old EIPs to discover the original author's new recommendation

[MicahZoltu]

How about the EIP authors decide when to use superseded-by? There is a good use case for it: see https://eips.ethereum.org/EIPS/eip-820 and https://eips.ethereum.org/EIPS/eip-1820.

This would certainly be more acceptable to me, though part of me feels like when an EIP becomes final its "ownership" shifts over to a public good, and I am hesitant to give power to the original authors whose views may not align with the broader community just because they happened to be the ones who penned the original EIP.

For example, say I was the author of ERC-20 and then years later I create ERC-N where I create a new token standard. Perhaps most people believe my ERC-N token standard is terrible, should I be able to put a mark on ERC-20 that basically tells people to go use ERC-N just because I happened to be the author of ERC-20? This gives me a huge amount of power that I probably shouldn't have. If ERC-N is a good idea, the community will adopt it, and they won't if it is a bad idea, independent of whether ERC-20 was popular or not.

[xinbenlv]

On Sat, Jul 16, 2022 at 05:21 Micah Zoltu @.***> wrote:

How about the EIP authors decide when to use superseded-by? There is a good use case for it: see https://eips.ethereum.org/EIPS/eip-820 and https://eips.ethereum.org/EIPS/eip-1820.

This would certainly be more acceptable to me, though part of me feels like when an EIP becomes final its "ownership" shifts over to a public good, and I am hesitant to give power to the original authors whose views may not align with the broader community just because they happened to be the ones who penned the original EIP.

For example, say I was the author of ERC-20 and then years later I create ERC-N where I create a new token standard. Perhaps most people believe my ERC-N token standard is terrible, should I be able to put a mark on ERC-20 that basically tells people to go use ERC-N just because I happened to be the author of ERC-20? This gives me a huge amount of power that I probably shouldn't have.

true. How about "suggested superseding eip" instead?

If ERC-N is a good idea, the community will adopt it, and they won't if it

is a bad idea, independent of whether ERC-20 was popular or not.

— Reply to this email directly, view it on GitHub https://github.com/ethereum/EIPs/issues/5265#issuecomment-1186170904, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAE4KRMLQIZMCW7DTLGQAJLVUKSOFANCNFSM53T45UWQ . You are receiving this because you authored the thread.Message ID: @.***>

[MicahZoltu]

true. How about "suggested superseding eip" instead?

It seems like this still has the same problem, where the person who happened to author some standard is in a privileged position that gives them power to shape how things progress in the future. Adding "suggested" helps a little but not much I think.

[xinbenlv]

On Sat, Jul 16, 2022 at 05:45 Micah Zoltu @.***> wrote:

true. How about "suggested superseding eip" instead?

It seems like this still has the same problem, where the person who happened to author some standard is in a privileged position that gives them power to shape how things progress in the future. Adding "suggested" helps a little but not much I think.

I think personally I feel the worry is much smaller than having a long old deprecated EIP draining scarced implementer attention when there are new better version. In the future maybe DAO can help how such decision are governed, but until that happens, i lean to weigh more on future compatibility.

The "no decision" that "no we will not add superseded-by EIP", is also a decision it self

The "no one shall have the power to point to another EIP" is also an implied power that Editors / EIP Stwards effectively hold the power of governing what can be and not be on the EIP

Hance we have to make some tradeoff with these implied power dynamics and considerations

—

Reply to this email directly, view it on GitHub https://github.com/ethereum/EIPs/issues/5265#issuecomment-1186175859, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAE4KRIU3YOB67Q53K3RMSLVUKVHDANCNFSM53T45UWQ . You are receiving this because you authored the thread.Message ID: @.***>

[Pandapip1]

It seems like this still has the same problem, where the person who happened to author some standard is in a privileged position that gives them power to shape how things progress in the future. Adding "suggested" helps a little but not much I think.

I don't see why that's much of a problem. If the old standard is better, there isn't an EIP police that will come and change your contract code. If an EIP author genuinely thinks a better alternative is available, then they are probably in the best position to correctly make that call.

[MicahZoltu]

My feeling is that we want each standard to stand on its own merit, and not be standing on the merit of the author's prior work. Someone can make a great standard, and then 2 years later make a terrible standard. Most people likely don't know which is better but they receive a breadcrumb to the new (terrible) standard when they should have gone and sought feedback from the broader community.

Imagine if today Fabian created a new token contract and updated ERC-20 to say that their new token superseded ERC-20. Many developers, particularly new developers, would run off and start implementing this new token even though there are a dozen token standards out there that are all better than ERC-20 and many of which may be better than the new standard that Fabian created.

---

Another thing to consider is that allowing the addition of superseded can introduce some pathological incentive games where someone who authors a popular EIP (ERC-20, ERC-721, ERC-1155, etc.) can sell rights to the superseded field to authors of future EIPs. Basically you just agree that you'll add a superseded field pointing at the highest bidder's EIP which can then be used for advertising a new standard. By making EIPs immutable, we avoid this entire can of worms.

[xinbenlv]

I feel very convinced by the pathological incentive games part.

I am not sure though, for who is the right one to make that decision to lock or not lock the EIP.

I share with you the sentiment that the person who holds the power to add ore reject a piece information might misuse/abuse that power. I am cautious regardless of that person is an author or, if disallowed, the power practically shift to the editor body.

If we give author this power, someone / some govern body shall be able to check and balance it. The same argument goes, if we give editor / stewards group this power, there is also a need for check and balance.

Maybe leave it to a DAO group consensus process? In the future I imagine the EIP process be governed by a DAO some properly setup governance mechanism.

Before the existence of such as DAO or governing body mechanism based on consensus, I am not fully convinced that we are the right group to decide how to limit author's power.

[xinbenlv]

I came across issue #4335 try to solve some similar problem. tagging author @Arachnid as FYI

[MicahZoltu]

Maybe leave it to a DAO? In the future I imagine the EIP process be governed by a DAO.

I'm pretty staunchly opposed to any sort of vote based governance because that deteriorates to tyranny of the majority or tyranny of the wealthy. If by DAO you mean an actually autonomous organization then that doesn't actually solve anything because we still need to define how exactly we make decisions on what is and what is not acceptable behavior, which is not made any simpler with a DAO.

[xinbenlv]

I realize when we use DAO to mean different things.

Lets drop the overused word "DAO".

What I mean is: when we dont trust individual or group of authors, we shall also be very cautious of giving editors or any other roles the power without check and balance.

Hence, I propose we leave this decision to a consensus group govenernce to drive the result.

[MicahZoltu]

Who is the group? How is consensus determined? How are group members added/removed?

[xinbenlv]

I share the same feeling with you in opposing to simple majority voting or wealth based voting.

My personal experience outside of Ehtereum or blockchain teaches me a lot of how governance is nontrival. If we get a chance I love to share more about my views and learn about yours.

Since we are also having a proposal of auctioning the EIP numbers, and many decisions of EIP process start to become increasing complecated, some governance needs to be set up.

I am not calling for any particular form(how) of governance, but to call for the start discussion of EIP governance(whether). I can do some brainstorming and I do have opinion about "how", but that would be second step. The first step is to address the question of "whether"

[github-actions[bot]]

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

[xinbenlv]

I plan to continue pursue this proposal.

[github-actions[bot]]

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

[github-actions[bot]]

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

[xinbenlv]

WIP

[github-actions[bot]]

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

[sambacha]

Moribund would be another possible method, both Yearn and Lido use this semantics. It applies to a subset of no longer relevant or applicable proposals/votes, whereas i see superseded concerning proposals that may have had some implementation issue due to incorrect specification but the underlying issue its addressing is still relevant/tangible

Etymology

moribund : ˈmɔːɹɪbʌnd

• Almost obsolete, nearing an end

[axic]

Just for the record Superseded was a status and superseded-by was a field in the past. They were removed after a number of discussions, and have been replaced by the withdrawal-reason field (#4198). I don't remember the specifics, but my PR was just the result of a number of people arguing about the fields and I just wanted to close out the conversation.

[sambacha]

Just for the record Superseded was a status and superseded-by was a field in the past. They were removed after a number of discussions, and have been replaced by the withdrawal-reason field (#4198). I don't remember the specifics, but my PR was just the result of a number of people arguing about the fields and I just wanted to close out the conversation.

thanks for the clarification 👍

[gcolvin]

Final EIPs cannot be superseded or withdrawn -- they are already in use and already the spec that is being followed. They can be corrected with errata, and new EIPs that do a better job can be written. Whether people prefer to use the new one is a social thing we can't control. But all of those old ERC-20 tokens need to keep on working.

[github-actions[bot]]

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

[Pandapip1]

Dismissing stale bot.

[github-actions[bot]]

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

[Pandapip1]

I would at least like the option to have an author-editable post-final-editable preamble field for notes after finalization.

[github-actions[bot]]

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

[Pandapip1]

Dismissing stale bot.

[github-actions[bot]]

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

[github-actions[bot]]

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

[YaroslavPysanskyi]

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

[github-actions[bot]]

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

[github-actions[bot]]

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

[bumblefudge]

@gcolvin :

Final EIPs cannot be superseded or withdrawn -- they are already in use and already the spec that is being followed. They can be corrected with errata, and new EIPs that do a better job can be written. Whether people prefer to use the new one is a social thing we can't control. But all of those old ERC-20 tokens need to keep on working.

@MicahZoltu :

Another thing to consider is that allowing the addition of superseded can introduce some pathological incentive games

If I'm understanding this PR correctly, only pre-final EIPs can be withdrawn and use withdrawal-reason.

Is it worth considering some kind of single-line frontmatter similar syntactically to withdrawal-reason, but with some other semantics specific to drawing extra attention to the Errata section in special cases after going to final status? Something with a key like postfinal-comment or errata-alert? Example values could be Please see errata section for security considerations added after finalizing or The authors recommend implementers also consider EIP-XXX, see errata section for details. It's probably worth considering as well whether this field without constraints could become an endrun around #4335 or the no-external-link policies (i.e. Please google 'MY-BIASED-REGISTRY' for further information 😅 )

NB @kdenhartog @kvhnuke

[github-actions[bot]]

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

[kdenhartog]

bump

[github-actions[bot]]

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

[Pandapip1]

I would support a section that could be modified post-final.

[github-actions[bot]]

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

[github-actions[bot]]

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

[bumblefudge]

whoops time flew how can we re-open this, @xinbenlv . seemed less urgent than repo-split/process-split so it kinda languished in backlog but i still want this :D

[Pandapip1]

We actually decided on a way to do this on the EIPIP meeting yesterday

[github-actions[bot]]

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

[github-actions[bot]]

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