You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The beaconchain is pushing the limits of software engineering on clients which are constantly finding new optimizations in order to maintain this high participation rate. In the last few weeks as the validator set reached a quarte of a million validators, reports of missed attestations have increased. I would be good to have some study of the data on-chain about missed attestations, late-included attestations, and soon sync committee participation. In rough terms the following are medium term objectives of this project
Develop tools to gather on-chain data and visualize it (here chaind is a good tool to gather data, so participants can either add functionality to it or use it as source for visualization apps)
Develop visualization schemes to understand the data: It's not really clear how to visualize attestation and/or participation data. Here are some examples:
Understanding the network topology of the p2p stack of Consensus layer.
Here are some concrete problems to tackle in the short term: understanding pools' role in late blocks or rather if clustering on mainnet is causing missed attestations. The thesis is that there are very large chunks of validator keys being run by pools on highly peered networks of their own, that produce blocks fast and they pack them with their own attestations. Those blocks are then arriving late to the single validator. If this is the case this should be checkable with on-chain data.
There are large lists of validators associated to pools in Beaconcha.in . Find those, just the first 5 pools would be more than enough.
Grab several blocks and gather the average attestation performance of these validators: that is, for each block, get the committe, match how many of these pool validators were supposed to attest and then how many did correctly.
Do the same for the network as a whole.
Find blocks with a large number of missed attestations: Given the information in 3) you can filter now some blocks that were statistically not voted.
On these blocks, determine the percentage of them that were proposed by the pools (see if it is more than their validator share)
On these blocks determine if pool validators attested with average performance as in 2)
Other projects include analysis of sync committee participation on Altair forked networks: find correlation between sync committee particpation and attestation participation and/or slot position in epoch. Specially useful would be to have tools (inexistent currently) to visualize sync committee participation.
The text was updated successfully, but these errors were encountered:
The beaconchain is pushing the limits of software engineering on clients which are constantly finding new optimizations in order to maintain this high participation rate. In the last few weeks as the validator set reached a quarte of a million validators, reports of missed attestations have increased. I would be good to have some study of the data on-chain about missed attestations, late-included attestations, and soon sync committee participation. In rough terms the following are medium term objectives of this project
Here are some concrete problems to tackle in the short term: understanding pools' role in late blocks or rather if clustering on mainnet is causing missed attestations. The thesis is that there are very large chunks of validator keys being run by pools on highly peered networks of their own, that produce blocks fast and they pack them with their own attestations. Those blocks are then arriving late to the single validator. If this is the case this should be checkable with on-chain data.
Other projects include analysis of sync committee participation on Altair forked networks: find correlation between sync committee particpation and attestation participation and/or slot position in epoch. Specially useful would be to have tools (inexistent currently) to visualize sync committee participation.
The text was updated successfully, but these errors were encountered: