Merge branch 'unstable' into cayman/ssz-api

.eslintrc.js

@@ -4,6 +4,7 @@ module.exports = {
     browser: true,
     es6: true,
     node: true,
+    // Performance tests still use mocha
     mocha: true,
   },
   globals: {
@@ -110,7 +111,11 @@ module.exports = {
       "error",
       {
         groups: ["builtin", "external", "internal", "parent", "sibling", "index"],
-        pathGroups: [{pattern: "@lodestar/**", group: "internal"}],
+        pathGroups: [
+          {pattern: "@lodestar/**", group: "internal"},
+          // We want mocks to be imported before any internal code
+          {pattern: "**/mocks/**", group: "internal"},
+        ],
         pathGroupsExcludedImportTypes: ["builtin"],
       },
     ],
@@ -201,24 +206,18 @@ module.exports = {
     },
     {
       files: ["**/test/**/*.test.ts"],
-      plugins: ["mocha", "chai-expect"],
-      extends: ["plugin:mocha/recommended", "plugin:chai-expect/recommended"],
+      plugins: ["vitest"],
+      extends: ["plugin:vitest/recommended"],
       rules: {
-        // We observed that having multiple top level "describe" save valuable indentation
-        // https://github.com/lo1tuma/eslint-plugin-mocha/blob/master/docs/rules/max-top-level-suites.md
-        "mocha/max-top-level-suites": "off",
-        // We need to disable because we disabled "mocha/no-setup-in-describe" rule
-        // TODO: Move all setup code to before/beforeEach and then disable async describe
-        // https://github.com/lo1tuma/eslint-plugin-mocha/blob/master/docs/rules/no-async-describe.md
-        "mocha/no-async-describe": "off",
-        // Use of arrow functions are very common
-        "mocha/no-mocha-arrows": "off",
-        // It's common to call function inside describe block
-        // https://github.com/lo1tuma/eslint-plugin-mocha/blob/master/docs/rules/no-setup-in-describe.md
-        "mocha/no-setup-in-describe": "off",
-        // We use to split before in small isolated tasks
-        // https://github.com/lo1tuma/eslint-plugin-mocha/blob/master/docs/rules/no-sibling-hooks.md
-        "mocha/no-sibling-hooks": "off",
+        "vitest/consistent-test-it": ["error", {fn: "it", withinDescribe: "it"}],
+        // We use a lot dynamic assertions so tests may not have usage of expect
+        "vitest/expect-expect": "off",
+        "vitest/no-disabled-tests": "warn",
+        "vitest/no-focused-tests": "error",
+        "vitest/prefer-called-with": "error",
+        "vitest/prefer-spy-on": "error",
+        // Our usage contains dynamic test title, this rule enforce static string value
+        "vitest/valid-title": "off",
       },
     },
     {

.github/workflows/docs-check.yml

@@ -39,12 +39,12 @@ jobs:
         run: scripts/wordlist_sort_check.sh
 
       - name: Build and collect docs
-        run: yarn build:docs
+        run: yarn docs:build
 
       # Run prettier check with fix after generating the docs. The CLI reference is formatted with prettier for
       # deployed version so this will fail if not "fixable"
       - name: Check docs format
-        run: yarn lint-docs:fix
+        run: yarn docs:lint:fix
 
       # Run spellcheck AFTER building docs, in case the CLI reference has issues
       - name: Spellcheck

.github/workflows/docs.yml

@@ -57,10 +57,10 @@ jobs:
         if: steps.cache-deps.outputs.cache-hit == 'true'
 
       - name: Build and collect docs
-        run: yarn build:docs
+        run: yarn docs:build
 
       - name: Lint built docs
-        run: yarn lint-docs:fix
+        run: yarn docs:lint:fix
 
       - name: Set up Python
         uses: actions/setup-python@v1

.github/workflows/test-sim.yml

@@ -16,6 +16,11 @@ on:
         description: Runtime DEBUG value
         required: false
         default: ""
+      genesisDelaySlots:
+        description: 'Number of slots delay before genesis'
+        required: true
+        type: number
+        default: 40
 
 env:
   GETH_DOCKER_IMAGE: ethereum/client-go:v1.11.6
@@ -56,6 +61,8 @@ jobs:
       - name: Sim tests multifork
         run: DEBUG='${{github.event.inputs.debug}}' yarn test:sim:multifork
         working-directory: packages/cli
+        env: 
+          GENESIS_DELAY_SLOTS: ${{github.event.inputs.genesisDelaySlots}}
 
       - name: Sim tests endpoints
         run: yarn test:sim:endpoints

.github/workflows/test.yml

@@ -160,8 +160,8 @@ jobs:
           check-latest: true
           cache: yarn 
 
-      # Remove when finished debugging core dumps
-      - uses: './.github/actions/setup-debug-node'
+      # # Remove when finished debugging core dumps
+      # - uses: './.github/actions/setup-debug-node'
 
       - name: Restore build cache
         id: cache-primes-restore
@@ -184,13 +184,14 @@ jobs:
           key: spec-test-data-${{ hashFiles('packages/validator/test/spec/params.ts') }}
 
       - name: Unit tests
-        id: unit_tests
+        # id: unit_tests
         # Rever to "yarn test:unit" when finished debugging core dumps
-        run: sudo sh -c "ulimit -c unlimited && /usr/bin/node-with-debug $(which yarn) test:unit"
+        # run: sudo sh -c "ulimit -c unlimited && /usr/bin/node-with-debug $(which yarn) test:unit"
+        run: yarn test:unit
 
-      # Remove when finished debugging core dumps
-      - uses: './.github/actions/core-dump'
-        if: ${{ failure() && steps.unit_tests.conclusion == 'failure' }}
+      # # Remove when finished debugging core dumps
+      # - uses: './.github/actions/core-dump'
+      #   if: ${{ failure() && steps.unit_tests.conclusion == 'failure' }}
 
       - name: Upload coverage data
         run: yarn coverage
@@ -320,12 +321,15 @@ jobs:
       # Run them in different steps to quickly identifying which command failed
       # Otherwise just doing `yarn test:spec` you can't tell which specific suite failed
       # many of the suites have identical names for minimal and mainnet
-      - name: Spec tests bls-general
-        run: yarn test:spec-bls-general
+      - name: Spec tests general
+        run: yarn test:spec:general
         working-directory: packages/beacon-node
+      - name: Spec tests bls
+        run: yarn test:spec:bls
+        working-directory: packages/beacon-node        
       - name: Spec tests minimal
-        run: yarn test:spec-minimal
+        run: yarn test:spec:minimal
         working-directory: packages/beacon-node
       - name: Spec tests mainnet
-        run: NODE_OPTIONS='--max-old-space-size=4096' yarn test:spec-mainnet
+        run: NODE_OPTIONS='--max-old-space-size=4096' yarn test:spec:mainnet
         working-directory: packages/beacon-node

.wordlist.txt

@@ -14,6 +14,7 @@ Chai
 ChainSafe
 Customizations
 DPoS
+DVs
 Discv
 DockerHub
 Dockerized
@@ -83,6 +84,7 @@ UPnP
 UTF
 VM
 Vitalik
+Vitest
 Wagyu
 api
 async
@@ -122,6 +124,7 @@ envs
 ephemery
 flamegraph
 flamegraphs
+getNetworkIdentity
 gnosis
 goerli
 heapdump
@@ -172,6 +175,7 @@ scalability
 secp
 sepolia
 sharding
+src
 ssz
 stakers
 subnet
@@ -186,6 +190,7 @@ util
 utils
 validator
 validators
+vitest
 wip
 xcode
 yaml

CONTRIBUTING.md

@@ -32,22 +32,40 @@ To run tests:
 - :test_tube: Run `yarn check-types` to check TypeScript types.
 - :test_tube: Run `yarn lint` to run the linter (ESLint).
 
+Note that to run `test:e2e`, first ensure that the environment is correctly setup by running the `run_e2e_env.sh` script.
+
+```sh
+GETH_DOCKER_IMAGE=ethereum/client-go:v1.11.6  NETHERMIND_DOCKER_IMAGE=nethermind/nethermind:1.18.0 ./scripts/run_e2e_env.sh start
+```
+
+Similarly, run `yarn download-spec-tests` before running `yarn test:spec`.
+
 Contributing to tests:
 
 - Test must not depend on external live resources, such that running tests for a commit must be deterministic:
   - Do not pull data from external APIs like execution JSON RPC (instead run a local node).
   - Do not pull unpinned versions from DockerHub (use deterministic tag) or Github (checkout commit not branch).
   - Carefully design tests that depend on timing sensitive events like p2p network e2e tests. Consider that Github runners are significantly less powerful than your development environment.
 
+### Common Issues
+
+**Error: [vitest] Cannot mock "../../src/db/repositories/index.js" because it is already loaded by "src/db/beacon.ts"**
+
+If you observe any error in tests with matching to above error message, that implies you are loading the mocks in the wrong order. The correct order is to import the mocks first and then the actual module. We suggest to import the mocks on very top before any local modules. 
+
+**✖ Error: Cannot find package 'async_hooks' imported from**
+
+If you observe following error running any of the test files that means you are running a file which itself or any dependency of that file imports `vitest`, but you are not running that file with `vitest` runner. Try running it with `yarn vitest` command, not with `node` command.
+
 ### Debugging Spec Tests
 
 - To fix errors always focus on passing all minimal tests first without running mainnet tests.
-- Spec tests often compare full expected vs actual states in JSON format. To better understand the diff it's convenient to use mocha's option `--inline-diffs`.
-- A single logical error can cause many spec tests to fail. To focus on a single test at a time you can use mocha's option `--bail` to stop at the first failed test
-- To then run only that failed test you can run against a specific file as use mocha's option `--grep` to run only one case
+- Spec tests often compare full expected vs actual states in JSON format.
+- A single logical error can cause many spec tests to fail. To focus on a single test at a time you can use vitest's option `--bail` to stop at the first failed test
+- To then run only that failed test you can run against a specific file as use vitest's filters to run only one case
 
 ```sh
-LODESTAR_PRESET=minimal ../../node_modules/.bin/mocha --config .mocharc.spec.yml test/spec/phase0/sanity.test.ts --inline-diffs --bail --grep "attestation"
+LODESTAR_PRESET=minimal yarn vitest --run --config vitest.spec.config.ts test/spec/phase0/sanity.test.ts
 ```
 
 ## Docker
@@ -229,6 +247,20 @@ Run script to download dashboards to `./dashboards` folder
 node scripts/download_dashboards.mjs
 ```
 
+## Contributing to Documentation
+
+When submitting PRs for documentation updates, build and run the documentation locally to ensure functionality before submission. For first time documentation contributors, install the python dependencies with `yarn docs:install`. Build the documentation locally with `yarn docs:build` and serve with `yarn docs:serve`
+
+Your locally served documentation will then be accessible at http://localhost:8000.
+
+If you run into build issues due to circular dependencies, branch switching or other incompatibilities, try cleaning your modules and rebuild your dependencies with:
+
+```sh
+yarn clean && yarn clean:nm && yarn && yarn build
+```
+
+We also use a spelling [word list](https://github.com/ChainSafe/lodestar/blob/unstable/.wordlist.txt) as part of our documentation checks. If using unrecognized words or abbreviations, please extend the word list to pass checks. Make sure the list is sorted with `./scripts/wordlist_sort.sh` and checked with `./scripts/wordlist_sort_check.sh` for sorting and duplicates.
+
 ## Label Guide
 
 Issues and pull requests are subject to the following labeling guidelines.

Dockerfile

@@ -39,9 +39,9 @@ FROM node:20-alpine
 WORKDIR /usr/app
 COPY --from=build_deps /usr/app .
 
-# NodeJS applications have a default memory limit of 2.5GB.
-# This limit is bit tight for a Prater node, it is recommended to raise the limit
+# NodeJS applications have a default memory limit of 4GB on most machines.
+# This limit is bit tight for a Mainnet node, it is recommended to raise the limit
 # since memory may spike during certain network conditions.
-ENV NODE_OPTIONS=--max-old-space-size=4096
+ENV NODE_OPTIONS=--max-old-space-size=8192
 
 ENTRYPOINT ["node", "./packages/cli/bin/lodestar"]

RELEASE.md

@@ -30,7 +30,7 @@ To start a new release, one of the Lodestar developers will communicate this via
   - This script may alternatively be run on the checked out `HEAD`:
     - `git checkout 9fceb02`
     - `yarn release:create-rc 1.1.0`
-- Open draft PR from `rc/v1.1.0` to `stable` with title `v1.1.0 release`.
+- Open draft PR from `rc/v1.1.0` to `stable` with title `chore: v1.1.0 release`.
 
 #### Manual steps (for example version `v1.1.0`, commit `9fceb02`):
 
@@ -42,7 +42,7 @@ To start a new release, one of the Lodestar developers will communicate this via
 - Commit changes
   - `git commit -am "v1.1.0"`
   - `git push origin rc/v1.1.0`
-- Open draft PR from `rc/v1.1.0` to `stable` with title `v1.1.0 release`.
+- Open draft PR from `rc/v1.1.0` to `stable` with title `chore: v1.1.0 release`.
 
 ### 2. Tag release candidate
 
@@ -76,13 +76,13 @@ For example: After 3-5 days of testing, is performance equal to or better than l
 - **Yes**: Continue to the next release step
 - **No**: If it a small issue fixable quickly (hot-fix)?
   - **Yes**: Merge fix(es) to `unstable`, push the fix(es) to `rc/v1.1.0` branch, go to step 2, incrementing the rc version
-  - **No**: abort the release. Close the `v1.1.0 release` PR, delete the branch, and start the whole release process over.
+  - **No**: abort the release. Close the `chore: v1.1.0 release` PR, delete the branch, and start the whole release process over.
 
 ### 4. Merge release candidate
 
 - Ensure step 2 testing is successful and there is sufficient consensus to release `v1.1.0`.
-- Approving the `v1.1.0 release` PR means a team member marks the release as safe, after personally reviewing and / or testing it.
-- Merge `v1.1.0 release` PR to stable **with "merge commit"** strategy to preserve all history.
+- Approving the `chore: v1.1.0 release` PR means a team member marks the release as safe, after personally reviewing and / or testing it.
+- Merge `chore: v1.1.0 release` PR to stable **with "merge commit"** strategy to preserve all history.
 - Merge stable `stable` into `unstable` **with merge commit** strategy. Due to branch protections in `unstable` must open a PR. If there are conflicts, those must be resolved manually. Gitflow may cause changes that conflict between stable and unstable, for example due to a hotfix that is backported. If that happens, disable branch protections in unstable, merge locally fixing conflicts, run lint + tests, push, and re-enable branch protections.
 
 ### 5. Tag stable release
@@ -130,7 +130,7 @@ A similar process for a stable release is used, with the three differences.
 - Switch to the hotfix release branch and cherrypick the inclusion(s) from the `unstable` branch to the hotfix release.
   - `git checkout rc/v1.1.1`
   - `git cherry-pick {commit}`
-- Open draft PR from `rc/v1.1.1` to `stable` with the title `v1.1.1 release`.
+- Open draft PR from `rc/v1.1.1` to `stable` with the title `chore: v1.1.1 release`.
 
 #### Manual steps (for example version `v1.1.1`, commit `8eb8dce`):
 
@@ -144,7 +144,7 @@ A similar process for a stable release is used, with the three differences.
 - Commit changes
   - `git commit -am "v1.1.1"`
   - `git push origin rc/v1.1.1`
-    Open draft PR from `rc/v1.1.1` to `stable` with the title `v1.1.1 release`.
+    Open draft PR from `rc/v1.1.1` to `stable` with the title `chore: v1.1.1 release`.
 
 ### 2. Tag release candidate