chore: remove repetitive words

Signed-off-by: acceptacross <csqcqs@gmail.com>

docs/pages/contribution/testing/simulation-tests.md

@@ -109,7 +109,7 @@ Here is an example of the table and how to interpret it:
 - `fork`: shows what fork is currently being tested
 - `eph`: During simulation tests the Lodestar repo is setup to use 8 slot per epoch so what is shown is the epoch number and the slot number within that epoch as `epoch/slot`
 - `slot`: The slot number that is currently being processed
-- `head`: If all clients have the the same head the first couple of bytes of the hash are shown. If all clients do not have the same head `different` is reported.
+- `head`: If all clients have the same head the first couple of bytes of the hash are shown. If all clients do not have the same head `different` is reported.
 - `finzed`: Shows the number of the last finalized slot
 - `peers`: The number of peers that each node is connected to. If all have the same number then only a single value is shown. If they do not have the same number of peers count for each node is reported in a comma-separated list
 - `attCount`: The number of attestations that the node has seen.

docs/pages/tools/heap-dumps.md

@@ -108,7 +108,7 @@ $ ./configure --debug
 # that a release version of node is already installed on the system
 $ make -C out BUILDTYPE=Debug -j$(nproc --all)
 
-# Move the debug version of node the the same folder that the release
+# Move the debug version of node the same folder that the release
 # version is installed in and name it `node_debug`.  This will put the
 # debug binary on the path and allow you to run it with the
 # `node_debug` command
@@ -127,7 +127,7 @@ $ yarn install
 
 # Ensure that all native modules are rebuilt with debug symbols. Some
 # modules are prebuilt, like classic-level, and the debug symbols may
-# not be included. If the the debugging exercise is focussed around
+# not be included. If the debugging exercise is focussed around
 # one of these dependencies, then you will need to manually clone those
 # repos and manually build them with debug symbols.
 $ npm rebuild --debug

packages/beacon-node/src/chain/bls/multithread/index.ts

@@ -438,7 +438,7 @@ export class BlsMultiThreadWorkerPool implements IBlsVerifier {
 
       // Send work package to the worker
       // If the job, metrics or any code below throws: the job will reject never going stale.
-      // Only downside is the the job promise may be resolved twice, but that's not an issue
+      // Only downside is the job promise may be resolved twice, but that's not an issue
 
       const [jobStartSec, jobStartNs] = process.hrtime();
       const workResult = await workerApi.verifyManySignatureSets(workReqs);

packages/beacon-node/src/execution/engine/payloadIdCache.ts

@@ -7,7 +7,7 @@ import {PayloadAttributesRpc} from "./types.js";
 // Idealy this only need to be set to the max head reorgs number
 const MAX_PAYLOAD_IDS = SLOTS_PER_EPOCH;
 
-// An execution engine can produce a payload id anywhere the the uint64 range
+// An execution engine can produce a payload id anywhere the uint64 range
 // Since we do no processing with this id, we have no need to deserialize it
 export type PayloadId = string;
 

packages/beacon-node/src/network/processor/gossipQueues/indexed.ts

@@ -18,7 +18,7 @@ const MINIMUM_WAIT_TIME_MS = 50;
  * This implementation tries to get the most items with same key:
  *   - index items by indexFn using a map
  *   - store keys with at least minChunkSize
- *   - on next, pick the the last key with minChunkSize, pop up to maxChunkSize items
+ *   - on next, pick the last key with minChunkSize, pop up to maxChunkSize items
  *   - on delete, pick the 1st key in the map and delete the 1st item in the list
  * Although it does not strictly follow LIFO, it tries to have that behavior:
  *   - On delete, get the first key and the first item of respective list

packages/beacon-node/src/util/queue/itemQueue.ts

@@ -93,7 +93,7 @@ export class JobItemQueue<Args extends any[], R> {
     this.runningJobs++;
 
     // If the job, metrics or any code below throws: the job will reject never going stale.
-    // Only downside is the the job promise may be resolved twice, but that's not an issue
+    // Only downside is the job promise may be resolved twice, but that's not an issue
     try {
       const timer = this.metrics?.jobTime.startTimer();
       this.metrics?.jobWaitTime.observe((Date.now() - job.addedTimeMs) / 1000);