cmd: beacon node simulation #3361
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3361 +/- ##
==========================================
- Coverage 58.68% 57.79% -0.90%
==========================================
Files 210 216 +6
Lines 30290 31622 +1332
==========================================
+ Hits 17777 18275 +498
- Misses 10617 11446 +829
- Partials 1896 1901 +5 ☔ View full report in Codecov by Sentry. |
pinebit
reviewed
Nov 8, 2024
|
pinebit
approved these changes
Nov 11, 2024
KaloyanTanev
added
the
merge when ready
KaloyanTanev
added a commit
that referenced
this pull request
Nov 19, 2024
Beacon node simulation test. This test aims to mimc the amount and types of requests a charon node sends to a beacon node. Requests are split into general cluster requests (independent of the amount of validators the charon node is servicing) and validator requests (requests are scaling based on the amount of validators). For lower number of validators (1 and 10) more aggressive approach is taken - you would see more frequent requests related to proposing and sync committee duties. As the validator number grows, the distribution evens out and gets closer to a real scenario. The time calculated for some duties is a sum of the RTT of multiple requests, because the duty requires that (i.e.: produce block + submit signed block), while others are the result of the RTT of a single request (i.e.: submit sync message). The tests performed are a best-estimate, it should be taken into an account that a lot of duties cannot be mimicked 1:1 - we cannot propose an actual block that will put an actual load on the beacon node. On submitting new signed block, the beacon node will quickly return 4XX error. In the future this can be optimised, to make as truthful of a request as possible, so that the BN is doing more work, before it recognises an issue. Running this test **should NOT** be considered an alternative to running a cluster on testnet to evaluate the performance of the Execution Layer and Consensus Layer nodes. Running an actual cluster on a network will always give you better perspective. category: feature ticket: none
Merged
obol-bulldozer bot
pushed a commit
that referenced
this pull request
Nov 20, 2024
Cherry-picked commits for v1.2-rc1. **Test command** - Add cluster lock and definition files to test peers [#3368](#3368) - Beacon node simulation [#3361](#3361) - General UX [#3370](#3370) - Create real blocks with MEV test [#3378](#3378) - Version check on beacon tests [#3379](#3379) - Rename test performance to test infra [#3380](#3380) - Output file improvements [#3384](#3384) - Custom number of validators for beacon node simulation [#3385](#3385) **Charon exit --all** - initial refactor [#3248](#3248) - add --all flag [#3272](#3272) - broadcast all exits [#3288](#3288) - fetch all exits [#3291](#3291) - enable exit all [#3296](#3296) - add custom testnet flags (to enable kurtosis testing) [#3317](#3317) - improve logging and error handling [#3347](#3347) - increase default Obol API timeout [#3353](#3353) **Misc** - Log leader index [#3334](#3334) - Add third Charon relay [#3227](#3227) - Fix promrated network overview stats [#3234](#3234) - Harden threshold parameter checks [#3242](#3242), [#3297](#3297) - Dependabot to bump only patch versions for our BLS library [#3352](#3352) - Optimize Dockerfile [#3281](#3281) **Tests / pipelines** - Fix flaky tests [#3309](#3309), [#3316](#3316), [#3332](#3332) - Disable intrange linter [#3282](#3282) - Create automate PR for release [#3310](#3310) - Use minor versions in pipelines [#3321](#3321) - Fix trigger-dispatch for release [#3351](#3351) [#3381](#3381) - Fix linter [#3307](#3307) (partially) **Docs** - Launchpad link broken [#3231](#3231) - Docs typos [#3236](#3236) [#3367](#3367) [#3369](#3369) All of the rest are tens of PRs with simple version bumps across the stack. category: misc ticket: none
12 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Beacon node simulation test. This test aims to mimc the amount and types of requests a charon node sends to a beacon node.
Requests are split into general cluster requests (independent of the amount of validators the charon node is servicing) and validator requests (requests are scaling based on the amount of validators).
For lower number of validators (1 and 10) more aggressive approach is taken - you would see more frequent requests related to proposing and sync committee duties. As the validator number grows, the distribution evens out and gets closer to a real scenario.
The time calculated for some duties is a sum of the RTT of multiple requests, because the duty requires that (i.e.: produce block + submit signed block), while others are the result of the RTT of a single request (i.e.: submit sync message).
The tests performed are a best-estimate, it should be taken into an account that a lot of duties cannot be mimicked 1:1 - we cannot propose an actual block that will put an actual load on the beacon node. On submitting new signed block, the beacon node will quickly return 4XX error. In the future this can be optimised, to make as truthful of a request as possible, so that the BN is doing more work, before it recognises an issue.
Running this test should NOT be considered an alternative to running a cluster on testnet to evaluate the performance of the Execution Layer and Consensus Layer nodes. Running an actual cluster on a network will always give you better perspective.
category: feature
ticket: none