ethereum/pm

Consensus-layer Call 132

ralexstokes opened this issue · 11 comments

ralexstokes commented

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

Chasing some final input on fixing a node-id mapping to attestation subnets (ethereum/consensus-specs#3623)

Relevant points about this:

  • This PR currently just focuses on mainnet, and I think its a strict improvement on what is currently in the specs (as there was a mistake in the last update)
  • I'm pushing for consensus on this, so that we can move forward implementing it in Lighthouse, which will form a base for our PeerDAS work
  • Given current conversations, I think it's general enough that it can accomodate PeerDAS requirements (to come in a future PR), but even if it isn't, we can abandon this idea in the peerdas custody column and still have the net benefit for current mainnet

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: ethereum/consensus-specs#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.

  • 👍1
nisdas commented

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: ethereum/consensus-specs#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.

  • 👍1
  • 🎉1
cskiraly commented

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.

lightclient commented

One specific thing I'd especially like to get feedback from CL devs on ethereum/EIPs#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

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

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.

  • 👍1
hwwhww commented

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.

  • 🚀4
Nashatyrev commented

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

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

closing in lieu of #1031