docs: modified docs

.github/workflows/README.md

@@ -1,14 +1,14 @@
 # Workflows
 
-- [Circuits profiling](./circuits_profile.yml)
+- [Circuits profiling](./circuits_profile.yaml)
   - Runs `nargo info` and stores the results into an artefact
-- [Circuits tests](./circuits_test.yml)
+- [Circuits tests](./circuits_test.yaml)
   - Runs `nargo test`
-- [Circuits E2E tests](./circuits_e2e.yml)
+- [Circuits E2E tests](./circuits_e2e.yaml)
   - Runs `nargo prove` & `nargo verify`
 - [Solidity tests](./contract_test.yml)
   - Runs `forge test`
-- [TypeScript E2E tests using solidity verifiers](./e2e_test.yml)
+- [TypeScript E2E tests using solidity verifiers](./e2e_test.yaml)
   - Runs `yarn test:e2e`
 - [Static checks](./static_checks.yaml)
   - Runs `yarn format:all:ci`

ethereum/README.md

@@ -21,7 +21,7 @@ Codebase also includes support for base Ethereum structures in Noir:
 - Mappings of Basic Ethereum data types: uint256, address, bytes32, hash
 - Fragment data structure, similar to Rust's slice, used for parsing data
 
-Additionally, we provide [smart contracts](./ethereum/contracts/src/EthereumHistoryVerifier.sol) that allow to verify inclusion of block in the chain for last 256 blocks.
+Additionally, we provide [smart contracts](./contracts/src/EthereumHistoryVerifier.sol) that allow to verify inclusion of block in the chain for last 256 blocks.
 
 ## Repository structure
 

ethereum/circuits/lib/src/merkle_patricia_proofs/README.md

@@ -19,7 +19,7 @@ pub fn verify_merkle_proof<MAX_PREFIXED_KEY_NIBBLE_LEN, MAX_VALUE_LEN, MAX_DEPTH
 )
 ```
 
-**verify_merkle_proof** doesn't return a boolean value but rather succeeds or fails depending on the correctness of given arguments. It takes four parameteres described below:
+**verify_merkle_proof** doesn't return a boolean value but rather succeeds or fails depending on the correctness of given arguments. It takes four parameters described below:
 
 ### Key
 

ethereum/circuits/lib/src/rlp/README.md

@@ -12,7 +12,7 @@ pub fn decode_string<N>(data: Fragment) -> RlpFragment;
 pub fn decode_list<N, NUM_FIELDS>(data: Fragment) -> RlpList<NUM_FIELDS>;
 ```
 
-**Note:** For string elements - offset points at the beginning of the data itself, while for lists - it points at the beginning of it's RLP Header.
+**Note:** For string elements - offset points at the beginning of the data itself, while for lists - it points at the beginning of its RLP Header.
 
 The library also exports a more performant special case version of `decode_list`, that can be used when the input consists exclusively of strings of length <= 55 bytes:
 
@@ -50,7 +50,7 @@ struct RlpFragment {
 
 `RlpFragment` contains the `offset` and `length` of the decoded item within the input data. It also contains the `data_type` of an item. Unlike the Fragment it does not contain the data as RLP data can have multiple fields and having multiple data copies is costly.
 
-Whe working with RLP data - it's a common pattern to have a structure (Tx, Log, Receipt) and its RLP encoding and comparing both field by field. To simplify this flow - we export some helper methods on `RlpFragment`. Each of those methods accepts `field_name`, `rlp` and `expected_value`.
+When working with RLP data - it's a common pattern to have a structure (Tx, Log, Receipt) and its RLP encoding and comparing both field by field. To simplify this flow - we export some helper methods on `RlpFragment`. Each of those methods accepts `field_name`, `rlp` and `expected_value`.
 
 - `field_name` is used in assertion messages
 - `rlp` contains the data to compare the `value` against using `offset` and `length` from `RlpFragment`