Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consensus-layer Call 132 #1010

Closed
ralexstokes opened this issue Apr 5, 2024 · 11 comments
Closed

Consensus-layer Call 132 #1010

ralexstokes opened this issue Apr 5, 2024 · 11 comments

Comments

@ralexstokes
Copy link
Member

ralexstokes commented Apr 5, 2024

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
Copy link

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.

@nisdas
Copy link

nisdas commented Apr 16, 2024

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.

@cskiraly
Copy link

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
Copy link
Contributor

@lightclient
Copy link
Member

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
Copy link
Member

parithosh commented Apr 17, 2024

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
Copy link

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
Copy link
Collaborator

hwwhww commented Apr 18, 2024

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
Copy link
Member

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
Copy link

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
Copy link
Member Author

closing in lieu of #1031

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants