Draft EIP, Discussions-to. Add updates and updated-by EIP Header Options for active EIPs

[edsonayllon]

---
eip: 2458
title: Add updates and updated-by EIP Header Options for active EIPs
author: Edson Ayllon (@edsonayllon) 
discussions-to: https://github.com/ethereum/EIPs/issues/2453
status: Draft
type: Informational
created: 2020-01-06
updates: 1
---

Simple Summary

Adds EIP header options updates and updated-by to frontmatter of active EIPs for use as needed. EIPs.

Scope

Adds header options. Changes process for updating active EIPs.

Abstract

EIP headers updates and updated-by are used for updating active EIPs. This is to make the improvement process of EIPs more modular, and have updates to existing active EIPs receive similar exposures to EIPs which replace existing final EIPs.

Motivation

Currently, EIP1 specifies EIP headers: updated, replaces, and superseded-by. Headers replaces and superseded-by indicates when an entire EIP is being replaced by another EIP, indicating when an EIP is now historical, and is updated by a new standard.

The header updated indicates the date an EIP has received an update by EIP authors and editors, an example EIP being EIP1. updated is reserved for EIPs in draft or active status.

In the case of active status, an EIP may receive an update, but these updates don't operate as with EIPs in final status, where a historical EIP is created, and the new EIP is referenced by the historical one. While these updates are not kept immutably, updates to active EIPs can be done modularly by creating a new EIP that goes through the standard discussion and auditing process EIPs undergo. The EIP headers updates and updated-by are to facilitate this modularity. Creating a new EIP also provides sufficient notification to affected stakeholders of an active EIP before that EIP is updated.

Specification

updated-by

updated-by is reserved for EIPs in active status. For an EIP in status active, updates to that EIP, which update the header updated, should be started by opening a new EIP to start vetting for that update. When an active EIP receives a new entry to header updated, an associated updated-by EIP listing should be included, where that newly listed EIP has reached final status, except where changes that don't change meaning, such as spelling and grammar corrections, are made.

updates should be included as an EIP header, as all EIP headers, and include a reference to an EIP designation. When multiple EIP designations are referenced, each should be separated by a comma. Example:

---
updated-by: EIP9999, EIP9998
---

updates

updates is reserved for EIPs updating EIPs in active status. An EIP listed as updates is implied to also be requires; only updates is needed for those EIP listings. Having an EIP listing updates does not necessarily mean that referenced EIP must reference back with an updated-by listing.

updates should be included as an EIP header, as all EIP headers, and include a reference to an EIP designation. When multiple EIP designations are referenced, each should be separated by a comma. Example:

---
updates: EIP1
---

Rationale

updates and updated-by apply only to EIPs in active status as updates to EIPs in final status are already handled by EIP headers superseded-by and replaces.

The syntax should align with previous EIP header syntax, as this EIP is not updating syntax, simply adding header options.

Backwards Compatibility

These EIP headers are optional and do not introduce compatibility issues.

Implementation

This EIP is an example implementation of updates, updating EIP1.

Security Considerations

This standard is informational and does not introduce technical security issues.

Copyright

Copyright and related rights waived via CC0.

[edsonayllon]

cc'ing contributors to EIP1: @axic, @fulldecent, @Arachnid, @Souptacular, @nicksavers, @timbeiko, @pirapira, @gcolvin, @xinbenlv, @tintinweb, @MicahZoltu, @corollari, @corollari, @guanqun, @gluk256, @chfast, @cdetrio, @Phistr90, @jamesray1

[fulldecent]

In every case where B will updates A, there will also already be the relation that B requires A.

I see limited utility in articulating this updates relationship because it should be obvious from context within the existing metadata.

[edsonayllon]

@fulldecent There could be cases of new functionality requiring another EIP, extending it, without updating it, such as EIPs requiring Account Versioning. requires doesn't imply the parent EIP will be updated by this child EIP, more-so implies that the child uses the parent. updates makes this distinction apparent. And, you're correct that including both update and requires is redundant. So, for EIPs listing updates it should imply requires—using updates instead of requires to be semantic.

[MicahZoltu]

EIPs are meant as technical specifications, not a process for deciding "what is current" or "what should be included in some software". For example, #1191 updates #155, but not everyone agrees that this is a good idea and should be implemented by all Ethereum wallets. It has been implemented in some major RSK wallets I believe, which are built off of EIPs. #1191 is a valid EIP and has been merged as such and is currently in Last Call (will likely go to Final), despite the fact that many believe that #155 should be the terminal EIP in that chain (for now).

Introducing a forward reference (updated-by) requires a mechanism for coming to agreement on when that forward reference is appropriate, and that is often a political process rather than a technical process so I would prefer to keep that out of the EIP process.

[edsonayllon]

@MicahZoltu EIPs are meant as technical specifications, not a process for deciding "what is current" or "what should be included in some software". For example, #1191 updates #155, but not everyone agrees that this is a good idea and should be implemented by all Ethereum wallets. It has been implemented in some major RSK wallets I believe, which are built off of EIPs. #1191 is a valid EIP and has been merged as such and is currently in Last Call (will likely go to Final), despite the fact that many believe that #155 should be the terminal EIP in that chain (for now).

EIPs are meant as existing standards which may or may not see an implementation in respective clients. EIPs which extend another EIP may exist, but whether it exists as a valid continuation that everyone should adapt over a prior EIP remains subjective. Do I correctly understand?

If my understanding is correct, that perspective is valid. If an EIP is made, and even reaches final status, it being final means it has matured to be implemented, but doesn't indicate a requirement for implementors to do so. And in the cases where an EIP has been implemented, and a new EIP extends it, in an intended versioning chain, it still is the implementors choice to do so.

Normative references that are meant to version existing EIPs are actually already included in EIP1, with replaces and superceded-by. Once an EIP has reached final status, I believe the only way to update it is creating a new one, and marking that old EIP as historical by using the superceded-by header, keeping EIP versioning immutable if it happens.

However, that's not the case with an EIP in active status. My suggestion is that updates not be used to replace entire standards, but propose an update for a piece of an existing standard when that standard is an active standard, and creates its own discussion around the validity of that update, such as this discussion here, introducing modularity when updating active EIPs.

@MicahZoltu Introducing a forward reference (updated-by) requires a mechanism for coming to agreement on when that forward reference is appropriate, and that is often a political process rather than a technical process so I would prefer to keep that out of the EIP process.

So, the header updated-by would bring about discussion whether or not a specification should receive an update. That discussion may be more subject, dealing with should instead of the technical specifications of whether something is technically sound (that it works). These conversations have the potential to become conversations dealing with ethics and philosophy, rather than pure technical integrity. What is correct in those cases may be more difficult to determine, and may never reach a definitive conclusion. Do I correctly understand?

Well, if an EIP is attempting to update an existing EIP for which it was not the original author, conversations on whether an update should happen are to be expected, they would be inevitable.

This concern more indicates that we don't have a process to ethically and systematically settle decisions involving ethics and philosophy, rather than pure technical specification. This indicates a need to develop such a process, possibly with multiple candidates available for use, which can be defined through EIPs of their own. I think I saw this issue with PropPOW, where the debate wasn't a technical debate, but more a debate of philosophy and maybe ethics, towards the middle and end of its maturation cycle.

But I think updated-by is actually more important than updates. At a given moment, for an active EIP, an author can push an update to their EIP with new information. These updates, from what I understand, don't have to go through auditing of EFI, last call, etc., statuses. This, though I think unlikely with informational EIPs, may introduce risk involving security, as the auditing process isn't done by the same standard. The header updated-by makes a suggested update to an active EIP temporarily modular, so discussion can occur around an update before being updated. And these updates, as they are done by creating a new EIP, go through the same auditing all EIPs go through, needing to pass all EIP stages before inclusion. This ensure updates are public and given sufficient consideration by the community they affect.

[edsonayllon]

I've updated the EIP keeping with the discussion points brought up.

[MicahZoltu]

At a given moment, for an active EIP, an author can push an update to their EIP with new information. These updates, from what I understand, don't have to go through auditing of EFI, last call, etc., statuses.

Final EIPs can only receive non-normative changes (e.g., typo corrections and such). A final EIP cannot have normative changes made to it.

[edsonayllon]

Final EIPs can only receive non-normative changes (e.g., typo corrections and such). A final EIP cannot have normative changes made to it.

As stated in what you quoted, that's in reference to active EIPs, not final EIPs.

[MicahZoltu]

Ah, I had forgotten about "Active" EIPs. I think they are pretty rare? EIP1 is the only one I know of.

Active – Some Informational and Process EIPs may also have a status of “Active” if they are never meant to be completed. E.g. EIP 1 (this EIP).

[edsonayllon]

I think EIP1 is the only active EIP at the moment, unless the EIP which tracks EFI EIPs is made, which would probably be active as well. Typically, it's best to push an EIP to the final track, and make any updates new EIPs that make the old EIP historical (aka superceded), similar to how ASTM International handles their standards. But, this EIP handles a case that's expected for all active EIPs, which are active because they expect to be updated.

[MicahZoltu]

I see. I didn't realize (upon-rereading I see that it was clear) that this proposal is only for Active EIPs. I suddenly care far less about this since "active" is only used for EIP-1 with no clear path to use it for anything other than that, and I don't care much about the conventions used in EIP-1.

[edsonayllon]

I'm closing this issue. Discussion continued in Ethereum Magicians. https://ethereum-magicians.org/t/eip-2458-add-updates-and-updated-by-eip-header-options-for-active-eips/4113