chore: remove repetitive words (Layr-Labs#509)

Signed-off-by: findmyhappy <[email protected]>

api/docs/disperser.md

@@ -339,7 +339,7 @@ Disperser defines the public APIs for dispersing blobs.
 
 | Method Name | Request Type | Response Type | Description |
 | ----------- | ------------ | ------------- | ------------|
-| DisperseBlob | [DisperseBlobRequest](#disperser-DisperseBlobRequest) | [DisperseBlobReply](#disperser-DisperseBlobReply) | This API accepts blob to disperse from clients. This executes the dispersal async, i.e. it returns once the request is accepted. The client could use GetBlobStatus() API to poll the the processing status of the blob. |
+| DisperseBlob | [DisperseBlobRequest](#disperser-DisperseBlobRequest) | [DisperseBlobReply](#disperser-DisperseBlobReply) | This API accepts blob to disperse from clients. This executes the dispersal async, i.e. it returns once the request is accepted. The client could use GetBlobStatus() API to poll the processing status of the blob. |
 | DisperseBlobAuthenticated | [AuthenticatedRequest](#disperser-AuthenticatedRequest) stream | [AuthenticatedReply](#disperser-AuthenticatedReply) stream | DisperseBlobAuthenticated is similar to DisperseBlob, except that it requires the client to authenticate itself via the AuthenticationData message. The protoco is as follows: 1. The client sends a DisperseBlobAuthenticated request with the DisperseBlobRequest message 2. The Disperser sends back a BlobAuthHeader message containing information for the client to verify and sign. 3. The client verifies the BlobAuthHeader and sends back the signed BlobAuthHeader in an 	 AuthenticationData message. 4. The Disperser verifies the signature and returns a DisperseBlobReply message. |
 | GetBlobStatus | [BlobStatusRequest](#disperser-BlobStatusRequest) | [BlobStatusReply](#disperser-BlobStatusReply) | This API is meant to be polled for the blob status. |
 | RetrieveBlob | [RetrieveBlobRequest](#disperser-RetrieveBlobRequest) | [RetrieveBlobReply](#disperser-RetrieveBlobReply) | This retrieves the requested blob from the Disperser's backend. This is a more efficient way to retrieve blobs than directly retrieving from the DA Nodes (see detail about this approach in api/proto/retriever/retriever.proto). The blob should have been initially dispersed via this Disperser service for this API to work. |

common/aws/dynamodb/client.go

@@ -184,7 +184,7 @@ func (c *Client) QueryIndexCount(ctx context.Context, tableName string, indexNam
 
 // QueryIndexWithPagination returns all items in the index that match the given key
 // Results are limited to the given limit and the pagination token is returned
-// When limit is is 0, all items are returned
+// When limit is 0, all items are returned
 func (c *Client) QueryIndexWithPagination(ctx context.Context, tableName string, indexName string, keyCondition string, expAttributeValues ExpresseionValues, limit int32, exclusiveStartKey map[string]types.AttributeValue) (QueryResult, error) {
 	var queryInput *dynamodb.QueryInput
 

contracts/src/core/EigenDAServiceManagerStorage.sol

@@ -26,7 +26,7 @@ abstract contract EigenDAServiceManagerStorage is IEigenDAServiceManager {
      * 
      * Note that this parameter needs to accommodate the delays which are introduced by the disperser, which are of two types: 
      *  - FinalizationBlockDelay: when initializing a batch, the disperser will use a ReferenceBlockNumber which is this many
-     *   blocks behind the current block number. This is to ensure that the the operator state associated with the reference block
+     *   blocks behind the current block number. This is to ensure that the operator state associated with the reference block
      *   will be stable.
      * - BatchInterval: the batch itself will only be confirmed after the batch interval has passed. 
      * 

docs/spec/attestation/bridging.md

@@ -6,7 +6,7 @@
 
 Bridging a DA attestion for a specific blob requires the following stages:
 - *Bridging the batch attestation*. This involves checking the aggregate signature of the DA nodes for the batch, and tallying up the total amount of stake the signing nodes.
-- *Verifying the blob inclusion*. Each batch contains a the root of a a Merkle tree whose leaves correspond to the blob headers contained in the batch. To verify blob inclusion, the associate Merkle proof must be supplied and evaluated. Furthermore, the specific quorum threshold requirement for the blob must be checked against the total amount of signing stake for the batch. 
+- *Verifying the blob inclusion*. Each batch contains a the root of a Merkle tree whose leaves correspond to the blob headers contained in the batch. To verify blob inclusion, the associate Merkle proof must be supplied and evaluated. Furthermore, the specific quorum threshold requirement for the blob must be checked against the total amount of signing stake for the batch. 
 
 For the first stage, EigenDA makes use of the EigenLayer's default utilities for managing operator state, verifying aggregate BLS signatures, and checking the total stake held by the signing operators.
 

indexer/accumulator.go

@@ -11,6 +11,6 @@ type Accumulator interface {
 	// Serialize object takes the accummulator object, and serializes it using the rules for the specified fork.
 	SerializeObject(object AccumulatorObject, fork UpgradeFork) ([]byte, error)
 
-	// DeSerialize object deserializes an accumulator object using the the rules for the specified fork.
+	// DeSerialize object deserializes an accumulator object using the rules for the specified fork.
 	DeserializeObject(data []byte, fork UpgradeFork) (AccumulatorObject, error)
 }