search

ethereum / pm

Project Management: Meeting notes and agenda items
Other
1.55k stars 313 forks source link

Consensus-layer Call 132 #1010

Closed ralexstokes closed 2 months ago

ralexstokes commented 3 months ago

Consensus-layer Call 132

prev: call 131

Meeting Date/Time: Thursday 2024/4/18 at 14:00 UTC Meeting Duration: 1.5 hours stream

  1. Electra
  2. Research, spec, etc
  3. Open discussion/Closing remarks
AgeManning commented 3 months ago

Chasing some final input on fixing a node-id mapping to attestation subnets (https://github.com/ethereum/consensus-specs/pull/3623)

Relevant points about this:

As a related side-note, does anyone have a good reason as to why we are rotating peers on the long-lived attestation subnets? I was originally introduced here: https://github.com/ethereum/consensus-specs/pull/1476

I currently can't think of a really good reason to keep to rotation and if we just keep it static, a lot of this simplifies. If we couple with the custody columns in PeerDAS, it would mean a peer custodys a column indefinitely.

Anyway, I want to propose removing rotation and updating the way we map node-id's to attestation subnets.

nisdas commented 3 months ago

As a related side-note, does anyone have a good reason as to why we are rotating peers on the long-lived attestation subnets? I was originally introduced here: https://github.com/ethereum/consensus-specs/pull/1476

Its been a while so maybe I mistaken, I think it was relevant for our old subnet backbone where our persistnet subnets would be randomly generated by each node. You would constantly rotate to prevent an adversary from being able to possibly map which validators you host. But given our current structure is fully deterministic across different rotation periods this becomes unnecessary. I agree with not rotating unless there is something else I missed.

cskiraly commented 3 months ago

As I understand, rotation has the potential advantage of re-randomizing the "meta-structure": the overlap between the set of nodes subscribed to different topics. At least, while it was done with local randomness, iI think it had that role. How much that feature is actually useful, is something to clarify.

mkalinin commented 3 months ago

I’d like to go over the following:

lightclient commented 3 months ago

One specific thing I'd especially like to get feedback from CL devs on https://github.com/ethereum/EIPs/pull/8432 is how they would like Requests to be sent over engine api. There seem to be two main options:

  1. We extend the ExecutionPayload with each individual Request type (deposit, exit, partial wx, etc) - this is a little more work for us but certainly doable
  2. We extend the ExecutionPayload with a list of all Request objects - each request would be differentiated by a json field type
parithosh commented 3 months ago

Toni and I would like to bring up the topic of a blob increase, specified in EIP-8452

I'd also like to briefly introduce a new tool: https://ethpandaops.io/posts/assertoor-introduction/

anderselowsson commented 3 months ago

In January I highlighted a research post that I had written on properties of issuance level. I have now finished a new research post that argues a little bit more deliberately for a change to the reward curve, and would just like to encourage researchers to have a look. So if there is time on the call, I could just highlight this. I have also finished a first simpler write-up directed more to the community, this one focusing on the foundations of minimum viable issuance.

hwwhww commented 3 months ago

CL spec v1.5.0-alpha.0 released! https://github.com/ethereum/consensus-specs/releases/tag/v1.5.0-alpha.0 It should be the pectra-devnet-0 target.

Nashatyrev commented 3 months ago

As a related side-note, does anyone have a good reason as to why we are rotating peers on the long-lived attestation subnets?

I believe the only reason for subnet rotation was hardening the sybil attack. An adversary may form his set of nodes for a single subnet for a limited period only. Due to the rotation (and particularly due to extra prefix bits) the set of adversary nodes would eventually be dispersed among other subnets in the next rotation period.

But assuming quite long rotation period we are aiming for (18 days) it is basically equivalent to a static mapping and is essentially not a great sybil attack countermeasure.

However I believe we need to reiterate possible consequences of a sybil attack to a DAS subnet. The attack may potentially result in significant liveness issues and looks more severe than a potential attack to an attestation or a sync committee subnet

cskiraly commented 3 months ago

But assuming quite long rotation period we are aiming for (18 days) it is basically equivalent to a static mapping and is essentially not a great sybil attack countermeasure.

I also question whether rotation period should really be that long (if we decide we need rotation). We can for example have part of the nodes rotating fast, and work on optimizing the mesh setup (or fast gossip-based distribution, or similar). I know the way we currently use GossipSub cannot cope with this, but I think it can be modified to allow faster changes. Maybe not for PeerDAS, but later.

ralexstokes commented 2 months ago

closing in lieu of #1031