Add EIP: On-chain upgrade signaling #9174
Conversation
github-actions
bot
added
c-new
File
|
eth-bot
added
e-consensus
|
not sure if this proposal is relevant to eth cc @SamWilsn as we may never go down this path |
|
Relevance should be based on whether this is an implementable proposal and if I can be heard. Hopefully it is and this can be merged as DRAFT. And then LATER, a stricter test is whether to implement this. |
EIPS/eip-9174.md
Outdated
| @@ -0,0 +1,144 @@ | |||
| --- | |||
| eip: 9174 | |||
| title: On-chain upgrade signaling | |||
There was a problem hiding this comment.
| title: On-chain upgrade signaling | |
| title: Onchain upgrade signaling |
I am not an editor. My personal preference is onchain.
There was a problem hiding this comment.
Well noted.
At this point, on-chain is the preferred usage across other publications in this repo.
I'm happy to adopt the less common usage if we can point to it as a best practice.
And either way that should be after merging this as draft.
Co-authored-by: Andrew B Coathup <28278242+abcoathup@users.noreply.github.com>
|
@g11tech requesting a merge for PR please so this can be discussed as draft |
|
Hi @g11tech, will you be blocking discussion on this draft, or may it please proceed to draft status? |
not really blocking discussion since discussion should ideally happen via eth-magicians. if this has enough indication from client devs, could merge it. otherwise need inputs of @SamWilsn and @lightclient on it. I will bring this PR to their notice in the discord channel of ethcarherders. you are free to join and present your case there as well. |
|
@g11tech So you are saying that a condition of making a draft for the EIP repo is that client devs must have in interest in building it. Did I read that correctly? |
|
Got it, thank you. What you are saying conflicts with EIP-1 which states:
If what you are saying is in fact the correct stance then EIP-1 should be updated to reflect this reality. I have worked on EIP-1 for years and it can be helpful if the process and criteria are properly documented and then documented process and criteria are faithfully implemented. Personal note: I have no hard feelings to you and this process, and I'll be happy whichever is the direction, and I'll make PRs as needed to make it easier for the next people. And I appreciate that you are passing this along. |
|
@timbeiko since this proposed EIP touches on upgrade process and also mentions EF, I would like to see your opinions on it |
|
I have updated this branch to remove language "it will be necessary for Ethereum Foundation to...". That may be out of scope of an EIP. And this specific EIP need not depend on that sentence. Does that address the issue and make this palatable as a draft? |
@poojaranjan has added to next EIPIP meeting for discussion, you can join us if you want. |
|
@g11tech I don't think we should block merging the EIP on my opinion, as it'd be better to have the discussion about the merits in a less ephemeral place than this PR. For the record, I disagree pretty strongly with the framing in line 66, even though I'm sympathetic towards improving the language used in the blog posts. |
|
Hi @timbeiko I have spread out the lines in 744b6e5. This means you can link to specific lines to focus where you strongly disagree with the framing. But like you said, this could all be much better discussed as a concrete draft, in draft status. @g11tech does this address your remaining concern with draft status? Can you please merge now? |
|
The commit 744b6e5 (as a parent of 667dcd0) contains errors. |
|
imo there already is a less ephemeral place, the eth magician link https://ethereum-magicians.org/t/eip-xxxx-on-chain-upgrade-signaling/22306, which is not contingent on accepting the EIP draft. the process is also not fully spec-ed in terms of what is the exact mechanism proposed, i.e what clients need to implement, voting logic, hardfork accepted/rejected logic... we anyway have a meeting on 15th, lets discuss it there |
@fulldecent so we concluded that if this PR is properly formatted and spec-ed in terms of idea, we will merge it. Could you address the above points that I raised so we can merge this. |
|
Thank you @g11tech, this is updated and ready for merge now |
|
|
||
| Ethereum consensus clients shall identify with a reference implementation having its equivalent behaviors. | ||
|
|
||
| Ethereum consensus clients shall include a `referenceImplementationHash` (specified below) field immediately following the `extraData` field in the block header. |
There was a problem hiding this comment.
in EL block header? i.e. execution payload in beacon block's body?
There was a problem hiding this comment.
Yes. This is a draft. So in draft we can discuss further and get ideas on this.
|
|
||
| Upgrade proposals (often referred to as hard fork EIPs) must specify an upgrade window and threshold. These parameters are implemented in the consensus client: | ||
|
|
||
| - `VOTING_WINDOW_BEGIN`: the first block (inclusive) to count votes. |
There was a problem hiding this comment.
is this slot based? is this a fixed slot start value that a proposal will add?
There was a problem hiding this comment.
It is intentionally unspecified in this EIP.
Yes, people using this EIP for upgrades are responsible to choose the start and end blocks however they like.
| - `REFERENCE_IMPLEMENTATION_HASH`: this is defined above. | ||
| - `REQUIRED_APPROVALS`: the minimum number of approvals necessary for the upgrade. | ||
|
|
||
| The difference (`VOTING_WINDOW_END` - `VOTING_WINDOW_BEGIN`) must be strictly greater than 14400 (about two days) and should be chosen to provide sufficient time to advertise the upgrade to network participants. |
There was a problem hiding this comment.
could you add details on how many fraction of validators will actually get to vote which is the fraction of validators having the block proposal in that particular window.
also add the justification for that particular fraction in the rational section.
There was a problem hiding this comment.
This proposal intentionally does not specify the fraction of validators.
Somebody using this EIP is responsible to chose the voting window. Their reasons may include a fraction of validators, or other reasons.
The note about two days is a strict lower bound. This is included only for a human persective because humans can sleep for up to one day at a time. And two is more than one.
It is actually expected that upgrades using this EIP will be MUCH more than two days, for safety. But again, this is a choice of the specific implementations. And EF has previously done software changes in under two days before (which is now disallowed under this EIP).
Ready for draft, please