Merge branch 'main' into jonas/tee-prover-service

Author: jonas089

docs/ARCHITECTURE.md

@@ -47,7 +47,7 @@ The prover service indexes EvolveEvm blocks for `EventDispatch` emissions. When
 In order for Celestia to mint synthetic tokens on behalf of the locked collateral tokens, the relayer must present two proofs:
 	- A state transition proof showing the EvolveEvm chain's current state evolved from a previously known (trusted) state. This allows Celestia to trust the new state root.
 	- A state inclusion proof showing that the commitment (message ID) is a valid Merkle leaf in the EvolveEvm chain state tree.
-The prover services runs zk circuits built using SP1:
+The prover service runs zk circuits built using SP1:
 	- The first circuit verifies sequential EvolveEvm header-to-header state transitions using [RSP](https://github.com/succinctlabs/rsp/tree/main) and additionally proves blob inclusion in Celestia’s data availability layer. The process is repeated for a batch of Celestia blocks.
     - The second circuit verifies Merkle inclusion of the commitment (message ID).
 6.	**ProverService submits proofs + message to Celestia.**
@@ -58,4 +58,4 @@ Celestia decodes the proofs, verifies them using its `ZKExecutionISM` module, an
 ### Token return flows
 
 If a user wishes to return tokens to the chain they originated from, the process closely mirrors the initial transfer.
-Instead of locking and minting, the protocol _burns_ the synthetic tokens on the destination chain and _unlocks_ the corresponding collateral token on the origin chain.
+Instead of locking and minting, the protocol _burns_ the synthetic tokens on the destination chain and _unlocks_ the corresponding collateral token on the origin chain.

docs/CONTRIBUTING.md

@@ -1,6 +1,6 @@
 # Contributing
 
-Thank you for your interest in contributing to repository! 🎉  
+Thank you for your interest in contributing to the repository! 🎉
 We welcome all contributions, whether it's fixing bugs, improving documentation, or implementing new features.
 
 ## Getting Started

hyperlane/README.md

@@ -115,7 +115,7 @@ Now that we've deployed the Hyperlane core and warp route infrastructure for a c
 we must establish a link between the two tokens and mailboxes.
 
 1. Enroll the synthetic token contract on Reth as the remote router contract on the celestia-app cosmosnative module.
-NOTE: Here we left-pad the 20byte EVM address to conform to the `HexAddress` spec of cosmosnative.
+NOTE: Here we left-pad the 20-byte EVM address to conform to the `HexAddress` spec of cosmosnative.
 
 NOTE: The following can be run from inside the `celestia-validator` service container, or from your host machine if you have access to a key for a funded account.
 
@@ -132,7 +132,7 @@ celestia-appd q warp remote-routers 0x726f757465725f6170700000000000000000000000
 ```
 
 2. Enroll the collateral token ID from the celestia-app cosmosnative module as the remote router on the synthetic token contract (EVM).
-Normally this should be possible to configure in a `warp-config.yaml` using the hyperlane CLI however, there isn't cosmosnative support yet.
+Normally this should be possible to configure in a `warp-config.yaml` using the hyperlane CLI however, there isn't any cosmos-native support yet.
 Instead, we attempt to do this manually by invoking the EVM contract directly.
 
 ```
@@ -194,7 +194,7 @@ cast call 0x345a583028762De4d733852c9D4f419077093A48 \
 
 #### Deploy a `HypNative` token on Evolve
 
-This guide will walkthrough the steps to deploy a `HypNative` token on EVM and a corresponding `Synthetic` token on Celestia and 
+This guide will walk through the steps to deploy a `HypNative` token on EVM and a corresponding `Synthetic` token on Celestia and 
 establish a link between the two.
 
 Ensure you have a valid private key set for deploying EVM contracts under the env variable `HYP_KEY`.
@@ -211,7 +211,7 @@ Example using the docker compose network in this repository:
 4. Select `No` for the trusted relayer ism.
 5. Select `Native` from the token list.
 
-Deploy the Warp contract using the `hyperlane` CLI. Provide the flag `--symbol ETH` to refer to the file created under `deployments/ETH` from the initial step. Alternatively provide 
+Deploy the Warp contract using the `hyperlane` CLI. Provide the flag `--symbol ETH` to refer to the file created under `deployments/ETH` from the initial step.
 Note, if running the CLI locally against the docker network then you will need to adjust the `rpcUrl` in `registry/chains` to use localhost.
 ```
 hyperlane warp deploy --registry ./hyperlane/registry --warp  --symbol ETH
@@ -237,7 +237,7 @@ celestia-appd q warp tokens
 
 #### Set the remote routers to establish a link between both tokens
 
-Finally we will set the remote router for both new tokens. Firstly on the EVM side and then on Celestia, the order in which this is done is does not matter.
+Finally we will set the remote router for both new tokens. Firstly on the EVM side and then on Celestia, the order in which this is done does not matter.
 
 Using `cast` we can invoke the contract directly to enroll the remote router providing both the `domain` and `Synthetic` token identifier.
 ```
@@ -273,4 +273,4 @@ cast send 0x032e1B988eB5Ac8F0C8617E09de92a664cABf37D \
   	69420 0000000000000000000000006A809B36CAF0D46A935EE76835065EC5A8B3CEA7 10000000 \
 		--private-key 0x82bfcfadbf1712f6550d8d2c00a39f05b33ec78939d0167be2a737d691f33a6a \
   	--rpc-url http://localhost:8545 --value 10000000
-```
+```

testdata/benchmarks/README.md

@@ -23,7 +23,7 @@ make stop
 ```
 
 Collect proof input data for a range of blocks.
-As mentioned in the `ev-exec` documentation, using the `--start` and `--blocks` flags allows the user to chose a starting height and number of blocks to gather input data for.
+As mentioned in the `ev-exec` documentation, using the `--start` and `--blocks` flags allows the user to choose a starting height and number of blocks to gather input data for.
 
 ```shell
 cargo run -p ev-exec-script --bin data-gen --release -- --start 15 --blocks 5
@@ -40,7 +40,7 @@ RUST_LOG=info cargo run -p ev-exec-script --release -- --execute --height 15 --o
 
 Using the outputs displayed on screen we can invoke the program for the subsequent blocks passing the `--trusted-height` and `--trusted-root` flags.
 Note, as we are chaining celestia blocks sequentially, we do not have a guarantee that each block will contain a `SignedData` blob for the EVM application.
-Thus, we explitcitly pass these flags to ensure empty blocks maintain a trusted height and state root moving forward.
+Thus, we explicitly pass these flags to ensure empty blocks maintain a trusted height and state root moving forward.
 
 ```shell
 RUST_LOG=info cargo run -p ev-exec-script --release -- --execute --height 16 --output-file block-15.json --trusted-height {N} --trusted-root {abcdef...}