Skip to content

Instantly share code, notes, and snippets.

@fjl

fjl/eip8-overview.md

Last active February 2, 2016 15:38
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save fjl/6c6d24dc1c7ab5d77c5c to your computer and use it in GitHub Desktop.
Save fjl/6c6d24dc1c7ab5d77c5c to your computer and use it in GitHub Desktop.
Download ZIP
Raw
eip8-overview.md

https://github.com/fjl/EIPs/blob/EIP-8/EIPS/eip-8.md

Pros/Cons of EIP-8 in the Context of Protocol Upgrades

Positives:

  • If both sides support a newer version of any of the protocols, it will be enabled.
  • Packet decoding is simple, clients know how many RLP list elements are defined to be meaningful for a given version and process only that many elements.
  • Downgrade attacks are not possible.

There's a downside, too:

  • Changing handshake encapsulation (i.e. change in ECIES, different curve) requires a different upgrade method, likely aided by discovery.

Future Considerations

RLPx v5 (new KDF, framing enabled) can be deployed as follows:

  • egress path: bump RLPx transport version to 5 and announce it in all handshakes.
  • ingress path: if remote ack version is >= 5, use v5 KDF and enable framing.

Another useful change would be to announce subprotocol-specific data in the handshake. Currently at least 2 full roundtrips are required before subprotocol parameters such as the genesis block hash are known. This change would enable dropping of useless connections with zero roundtrips. It can be deployed as follows:

  • egress path: bump RLPx transport version to 6, unconditionally add subprotocol metadata to all RLPx handshakes.
  • ingress path: if remote ack version is >= 6, also decode subprotocol information from the handshake and skip hello, subprotocol hello messages.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment