chore: fix some typos

contracts/AttestData.sol

@@ -182,8 +182,8 @@ contract DataAttestationSingle is LoadInstances, SwapProofCommitments {
 
     /**
      * @notice EZKL P value
-     * @dev In order to prevent the verifier from accepting two version of the same pubInput, n and the quantity (n + P),  where n + P <= 2^256, we require that all instances are stricly less than P. a
-     * @dev The reason for this is that the assmebly code of the verifier performs all arithmetic operations modulo P and as a consequence can't distinguish between n and n + P.
+     * @dev In order to prevent the verifier from accepting two version of the same pubInput, n and the quantity (n + P),  where n + P <= 2^256, we require that all instances are strictly less than P. a
+     * @dev The reason for this is that the assembly code of the verifier performs all arithmetic operations modulo P and as a consequence can't distinguish between n and n + P.
      */
     uint256 constant ORDER =
         uint256(
@@ -444,8 +444,8 @@ contract DataAttestationMulti is LoadInstances, SwapProofCommitments {
 
     /**
      * @notice EZKL P value
-     * @dev In order to prevent the verifier from accepting two version of the same pubInput, n and the quantity (n + P),  where n + P <= 2^256, we require that all instances are stricly less than P. a
-     * @dev The reason for this is that the assmebly code of the verifier performs all arithmetic operations modulo P and as a consequence can't distinguish between n and n + P.
+     * @dev In order to prevent the verifier from accepting two version of the same pubInput, n and the quantity (n + P),  where n + P <= 2^256, we require that all instances are strictly less than P. a
+     * @dev The reason for this is that the assembly code of the verifier performs all arithmetic operations modulo P and as a consequence can't distinguish between n and n + P.
      */
     uint256 constant ORDER =
         uint256(

docs/advanced_security/public_commitments.md

@@ -20,7 +20,7 @@ You can also implement such a pattern using Halo2's `Fixed` columns _if the priv
 
 The annoyance in using `Fixed` columns comes from the fact that they require generating a new verifying key every time a new set of commitments is generated.
 
-> **Example:** Say for instance an application leverages a zero-knowledge circuit to prove the correct execution of a neural network. Every week the neural network is finetuned or retrained on new data. If the architecture remains the same then commiting to the new network parameters, along with a new proof of performance on a test set, would be an ideal setup. If we leverage `Fixed` columns to commit to the model parameters, each new commitment will require re-generating a  verifying key and sharing the new key with the verifier(s). This is not-ideal UX and can become expensive if the verifier is deployed on-chain. 
+> **Example:** Say for instance an application leverages a zero-knowledge circuit to prove the correct execution of a neural network. Every week the neural network is finetuned or retrained on new data. If the architecture remains the same then committing to the new network parameters, along with a new proof of performance on a test set, would be an ideal setup. If we leverage `Fixed` columns to commit to the model parameters, each new commitment will require re-generating a  verifying key and sharing the new key with the verifier(s). This is not-ideal UX and can become expensive if the verifier is deployed on-chain. 
 
 An ideal commitment would thus have the low cost of a `Fixed`  column but wouldn't require regenerating a new verifying key for each new commitment.
 

src/bindings/universal.rs

@@ -64,7 +64,7 @@ impl From<InnerEZKLError> for EZKLError {
 /// Encode verifier calldata from proof and ethereum vk_address
 #[cfg_attr(feature = "ios-bindings", uniffi::export)]
 pub(crate) fn encode_verifier_calldata(
-    // TODO - shuold it be pub(crate) or pub or pub(super)?
+    // TODO - should it be pub(crate) or pub or pub(super)?
     proof: Vec<u8>,
     vk_address: Option<Vec<u8>>,
 ) -> Result<Vec<u8>, EZKLError> {

src/eth.rs

@@ -78,8 +78,8 @@ abigen!(
     contract QuantizeData {
         /**
          * @notice EZKL P value
-         * @dev In order to prevent the verifier from accepting two version of the same instance, n and the quantity (n + P),  where n + P <= 2^256, we require that all instances are stricly less than P. a
-         * @dev The reason for this is that the assmebly code of the verifier performs all arithmetic operations modulo P and as a consequence can't distinguish between n and n + P.
+         * @dev In order to prevent the verifier from accepting two version of the same instance, n and the quantity (n + P),  where n + P <= 2^256, we require that all instances are strictly less than P. a
+         * @dev The reason for this is that the assembly code of the verifier performs all arithmetic operations modulo P and as a consequence can't distinguish between n and n + P.
          */
         uint256 constant ORDER =
             uint256(