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 86 Agenda #521

Closed
djrtwo opened this issue May 3, 2022 · 6 comments
Closed

Consensus-layer Call 86 Agenda #521

djrtwo opened this issue May 3, 2022 · 6 comments

Comments

@djrtwo
Copy link
Collaborator

djrtwo commented May 3, 2022

Consensus-layer Call 86 Agenda

prev: call 85

Meeting Date/Time: Thursday 2022/5/5 at 14:00 UTC
Meeting Duration 1.5 hours
live stream

  1. Merge
    • Testing
    • Bomb update
    • Ropsten Beacon Chain launch. who runs vals, is it permissioned, etc
  2. Other client updates (if any)
  3. Research, spec, etc
    • episub discussion
    • builder api status
  4. Open Discussion/Closing Remarks
@AgeManning
Copy link

Unrelated to the merge -
I've been chasing bandwidth consumption (which the merge is likely to increase) and ways to improve it. There is a minimal addition to gossipsub that we can make that should help (hopefully substantially). It can be backwards compatible, so Lighthouse could implement it on its own, but am chasing other client teams interest in building it out.

It's called episub and has been a planned upgrade for gossipsub for a while, but no one really had the need for it, but given our current and future message sizes, I think we should build it. We (Lighthouse) are happy to prototype and build the first implementation.

@lightclient
Copy link
Member

lightclient commented May 5, 2022

Can we please discuss the status of the Builder API?

We received a lot of good feedback on the JSON-RPC version, but it seems CL teams would like to switch to beacon-api style endpoints. I've started the migration, but would like to make sure we're all on the same page. Also, not sure how to continue pushing this PR into the beacon-apis forward?

@benjaminion
Copy link

Call notes

@Nashatyrev
Copy link
Member

Unrelated to the merge - I've been chasing bandwidth consumption (which the merge is likely to increase) and ways to improve it. There is a minimal addition to gossipsub that we can make that should help (hopefully substantially). It can be backwards compatible, so Lighthouse could implement it on its own, but am chasing other client teams interest in building it out.

It's called episub and has been a planned upgrade for gossipsub for a while, but no one really had the need for it, but given our current and future message sizes, I think we should build it. We (Lighthouse) are happy to prototype and build the first implementation.

@AgeManning
As far as I understood the major episub advantage over gossipsub is that it reduces network bandwidth by arranging mesh routes more efficiently?

From my perspective the main question is how this optimization could affect BFT property of the network?

The quick idea is that an attacker may populate nodes which propagates messages very promptly (by just omitting message validation) and these nodes could finally become key points in the network and potentially perform a large class of attacks.

@AgeManning
Copy link

Yeah, fair concern. It would be good to test this scenario out and see how it performs.

I'll try and spec something up, so its clearer for everyone interested.

The general idea is to implement CHOKE/UNCHOKE control messages. We take some statistical distribution of timing of messages from our mesh peers. The ones sending us slow duplicates over some period, we send CHOKE to. This informs them to stop sending us messages in the mesh, but instead ALWAYS send us gossip in their heartbeat (rather than them randomly selecting us). If we start seeing a bunch of gossip first, then we UNCHOKE that node.

Also if we see a bunch of gossip from peers not in the mesh delivering us messages first, we may want to add them to the mesh.

@timbeiko
Copy link
Collaborator

Closed in favor of #527

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

6 participants