Rollback EIP-712 from "final" to "draft" OR deprecate EIP-712 with a new one
xinbenlv opened this issue · comments
EIP-1 mandates a "final" status to be terminal. But the current snapshot of EIP-712 is flawed in various ways, as discussed in #5457
More over, it has two "specification“ sections.
We need to make the following decision:
Option 1: rollback EIP-712 status from FINAL back to DRAFT to allow massive update, a one time exception to EIP-1 mandate
Option 2: encourage original authors of EIP-712 to write a new EIP with new number that "updates" EI-712(thus considered EIP-712 deprecated) .
Also feel free to suggest other options.
@Pandapip1 @lightclient @SamWilsn @axic @MicahZoltu @gcolvin for thoughts
Actually, there is a legal equivalent to having multiple specification and that is the condominum where 2 powers can exercise dominion over the same physical space. The most classic is the Antartica Treaty where all signatories agree to suspend their claims (still pending). However, reading the actual EIP it seems that the 2nd label Specification seems to be misedit, what we in legal circles would consider a scrivener error or corruption between intent of parties and written down contract/smart contract.
So an alternative to roll-back when it is not debated and would be a unilateral action, is to define an extension of EIP-1 that when a supermajority vote consensus is a scrivener error, the final EIP-number becomes EIP-number minus (a version number according to the RFC standard, eg negative 0.1 for transcription errors, negative -1 for when the meaning changes.
@drllau ... CC: LexDAO clinic EIP subgroup
Final EIPs are final, warts and all. There are many problems with many EIPs, but we have to live with them. People have already implemented 712 and we cannot undo that, so we are stuck with it. I recommend creating a new EIP that fixes those issues.
I haven't time to study this particular case right now but in general ...
Our intent way back when, with @Souptacular and @Arachnid, was that yes, Final is Final. Why? Because the Editors didn't change the status to Final until after the EIP was on the mainnet, at which point it was too late to change the reality.In the case where the EIP failed to desc ribe the behavior of the mainnet we allowed for Errata, but we failed to define an EIP section for those. This might be the first time it has become an issue.
We now go to Final before we put code on the mainnet, but I don't think that changes much -- Final EIPs need to describe what is on the mainnet. And we can "deprecate" an EIP, but that would only apply to future versions of the mainnet.
So I would say that if 712 is not yet on the mainnet it can be changed to reflect what we intend to go on the mainnet. If 712 is already on the mainnet, but the two do not correspond, then we need an Errata section to fix that.
@MicahZoltu and @gcolvin thanks!
Unless I read you wrong, I think both of you effectively want Option 2 right?
Is 712 on the mainnet?
712 is "on mainnet" (note: it isn't a core EIP).
I don't agree with either option, because I don't agree with deprecation. Someone can write a new EIP and promote it and encourage people to use it over 712, but people who want to use 712 can continue to use 712 and should not be forced to accept it as deprecated if they still like it.
people who want to use 712
Nobody can use 712. It has two mutually exclusive specifications.
712 is "on mainnet" (note: it isn't a core EIP).
Aha. So implementations aren't forced to be in consensus the way clients are.
Nobody can use 712. It has two mutually exclusive specifications.
From the discussion at #5457 it's clear that nobody has (or can) implement the spec as written, but that most (maybe all) implementations have implemented it in same way. So we have that kind of consensus, and the right thing to do is fix this as an errata.
712 is "on mainnet" (note: it isn't a core EIP).
Aha. So implementations aren't forced to be in consensus the way clients are.
Nobody can use 712. It has two mutually exclusive specifications.
From the discussion at #5457 it's clear that nobody has (or can) implement the spec as written, but that most (maybe all) implementations have implemented it in same way. So we have that kind of consensus, and the right thing to do is fix this as an errata.
Yes, @gcolvin , it came to our consensus that at the current snapshot of 712 it's incorrect and unimplementable. It needs some form of fixing. Recognizing the unimplementability, three options I personally put on the table:
- Option (1) Fix the EIP in the number of 712, but change status from FINAL to something else.
- Option (2) Fix fix EIP, but give it a different EIP-number, e.g. EIP-5712 updates(supersedes) EIP-712.
- Option (3) Fix EIP in the number of 712, but during the fixing time, keep status as FINAL
I have no concern for option 1 or 2, but i held pretty strong objection against option 3, reason being it undermines our credibility of "FINAL". Reader shall not read and attempt to implement a "FINAL"-marked EIP only to realize it is undergone normative change - assuming the fixing will take weeks to finalize and verified. I hope I make my rationale and thinking process clear. We look forward to your guidance our OG @gcolvin
There has been no activity on this issue for 1 week. It will be closed after 3 months of inactivity.
We need to specify an Errata section for EIPs and a process for creating them, @xinbenlv
There has been no activity on this issue for 1 week. It will be closed after 3 months of inactivity.
Closing for now. Will revisit when another report of 712 error comes up.