Consensus-layer Call 86 Agenda

[djrtwo]

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]

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]

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]

Call notes

[Nashatyrev]

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]

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]

Closed in favor of #527