EIP 2481: Adding request IDs to ETH protocol request and response objects #2481
Conversation
cburgdorf
force-pushed
the
christoph/add-request-id-to-eth-protocol
branch
from
c34b698
to
cdb7fe6
Compare
cburgdorf
force-pushed
the
christoph/add-request-id-to-eth-protocol
branch
from
cdb7fe6
to
0823cec
Compare
cburgdorf
force-pushed
the
christoph/add-request-id-to-eth-protocol
branch
3 times, most recently
from
ec128d5
to
d7fcfd9
Compare
cburgdorf
force-pushed
the
christoph/add-request-id-to-eth-protocol
branch
from
d7fcfd9
to
9eee53c
Compare
cburgdorf
force-pushed
the
christoph/add-request-id-to-eth-protocol
branch
from
9eee53c
to
0cdf542
Compare
|
Who do I need to bribe for this to get an EIP number assigned? Or should I just assign |
cburgdorf
changed the title
|
@cburgdorf You must implement it in Geth |
|
|
That is the convention, probably also explained in EIP-1? |
| <!--"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the EIP.--> | ||
| This document proposes a way to increase the efficiency of the `eth` networking protocol while at the same time reducing complexity in Ethereum node implementations. It does so by introducing a request id to all requests which their corresponding responses must include. | ||
|
|
||
| ## Abstract |
There was a problem hiding this comment.
This is quite a mouthful abstract 😉
|
@axic I can't comment on the process requirements, but the content is something we've all agreed we should go forward with, so fine by me. Perhaps @cburgdorf, bring it up on next ACD call just so we have a "public debate" before going ahead with rolling it out. Just so that the EIP doesn't get passed behind closed doors. |
|
The networking EIPs usually ignore "any process of EIPs", anyway 😉 Maybe also because the slow throughput of the EIP repo. To me this looks ok as a draft. Ideally it would be in "last call" before complete rollout. |
EIPS/eip-2481.md
Outdated
| ## Security Considerations | ||
| <!--All EIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life cycle of the proposal. E.g. include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. EIP submissions missing the "Security Considerations" section will be rejected. An EIP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers.--> | ||
|
|
||
| None? |
There was a problem hiding this comment.
I would it shouldn't go "final" with a question mark.
There was a problem hiding this comment.
Initially I was shy to deny security implications entirely but the EIP has had some 👀 on it by now and nobody has brought up any concerns. I just removed the question mark now.
|
@karalabe @axic I've proposed this for the next ACD call on Friday and will attend the meeting to present it. |
|
Lets merge this as a proper draft. |
…ects (ethereum#2481) * Add EIP arguing for request ids * Assign EIP number 2481 * Add link to draft implementation in Trinity * Fix spelling issues * Change file name * Remove question mark from security considerations
…ects (ethereum#2481) * Add EIP arguing for request ids * Assign EIP number 2481 * Add link to draft implementation in Trinity * Fix spelling issues * Change file name * Remove question mark from security considerations
…ects (ethereum#2481) * Add EIP arguing for request ids * Assign EIP number 2481 * Add link to draft implementation in Trinity * Fix spelling issues * Change file name * Remove question mark from security considerations
No description provided.