core/tracker: track inclusion events #2299
Conversation
| inclCheckLag = 16 | ||
| // inclTrimLag is the number of slots after which we delete cached submissions. | ||
| // This matches scheduler trimEpochOffset. | ||
| inclTrimLag = 32 * 3 |
There was a problem hiding this comment.
decrease from 3 to 1 epoch since that is max at this point.
There was a problem hiding this comment.
just wondering, what if we are running charon in a network with slots_per_epoch != 32, for example, gnosis? Shouldn't we read this kind of information from beacon node?
If we are taking slot as smallest unit in any network then its fine to hardcode it to 32.
There was a problem hiding this comment.
Yeah not so worried about this, 32 slots is fine, even for gnosis chain.
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #2299 +/- ##
==========================================
+ Coverage 53.75% 53.88% +0.12%
==========================================
Files 191 191
Lines 25767 25792 +25
==========================================
+ Hits 13852 13897 +45
+ Misses 10227 10203 -24
- Partials 1688 1692 +4
☔ View full report in Codecov by Sentry. |
| inclCheckLag = 16 | ||
| // inclTrimLag is the number of slots after which we delete cached submissions. | ||
| // This matches scheduler trimEpochOffset. | ||
| inclTrimLag = 32 * 3 |
There was a problem hiding this comment.
just wondering, what if we are running charon in a network with slots_per_epoch != 32, for example, gnosis? Shouldn't we read this kind of information from beacon node?
If we are taking slot as smallest unit in any network then its fine to hardcode it to 32.
| @@ -17,6 +17,10 @@ maintain system performance. | |||
| - *Summary*: failed to broadcast duty to beacon node | |||
| - *Details*: Reason `bcast` indicates that beacon node returned an error while submitting aggregated duty signature to beacon node. | |||
|
|
|||
| ### Failure Reason: `chain_inclusion` | |||
| - *Summary*: duty not included on-chain | |||
| - *Details*: Reason `chain_inclusion` indicates that even though charon broadcasted the duty successfully, it wasn`t included in the beacon chain. This is expected for up to 20% of attestations. It may however indicate problematic charon broadcast delays or beacon node network problems. | |||
There was a problem hiding this comment.
nit: do we have data that only 80% broadcasted attestations end up on-chain?
There was a problem hiding this comment.
ppromrated network effectiveness:
There was a problem hiding this comment.
Although that might not be accurate, here is better data. Seems like 5% is more realistic for goerli at least. Well see how mainnet does after releasing v0.16.
Co-authored-by: Dhruv Bodani <[email protected]>
corverroos
added
the
merge when ready
Extends tracker duty failure reasons to include "chain inclusion" results. Duties will subsequently only be marked as success if included onchain, and accordinlgy marked as failed if not included onchain.
Note that chain inclusion is only checked if the duty was broadcasted, so this doesn't actually "make duty failures objective", since if the local node failed to broadcast, it will not check inclusion and will mark the duty as failed regardless of actual results.
category: feature
ticket: #2200