chore(gateway-contracts): add upgrade test

Author: melanciani

gateway-contracts/contracts/examples/CoprocessorContextsV2Example.sol

@@ -0,0 +1,32 @@
+// SPDX-License-Identifier: BSD-3-Clause-Clear
+
+pragma solidity ^0.8.24;
+
+import "../CoprocessorContexts.sol";
+
+contract CoprocessorContextsV2Example is CoprocessorContexts {
+    /// @notice Name of the contract
+    string private constant CONTRACT_NAME = "CoprocessorContexts";
+
+    /// @notice Version of the contract
+    uint256 private constant MAJOR_VERSION = 1000;
+    uint256 private constant MINOR_VERSION = 0;
+    uint256 private constant PATCH_VERSION = 0;
+
+    /// @notice Getter for the name and version of the contract
+    /// @return string representing the name and the version of the contract
+    function getVersion() external pure virtual override returns (string memory) {
+        return
+            string(
+                abi.encodePacked(
+                    CONTRACT_NAME,
+                    " v",
+                    Strings.toString(MAJOR_VERSION),
+                    ".",
+                    Strings.toString(MINOR_VERSION),
+                    ".",
+                    Strings.toString(PATCH_VERSION)
+                )
+            );
+    }
+}

gateway-contracts/docs/getting-started/contracts/coprocessor_contexts.md

@@ -1,7 +1,6 @@
 # CoprocessorContexts contract
 
-This section describes the `CoprocessorContexts` contract. It is used to manage the lifecycle of coprocessors for the
-fhevm Gateway protocol.
+This section describes the `CoprocessorContexts` contract. It is used to manage the lifecycle of coprocessors for the fhevm Gateway protocol.
 
 Several settings are stored in the contract, which can be separated in several categories:
 
@@ -11,21 +10,18 @@ Several settings are stored in the contract, which can be separated in several c
 
 ## Coprocessor
 
-A coprocessor is part of a set of multiple coprocessors, called a coprocessor [context](#coprocessor-context). They are
-used to :
+A coprocessor is part of a set of multiple coprocessors, called a coprocessor [context](#coprocessor-context). They are used to :
 
 - perform FHE computations on ciphertexts
 - verify inputs' zero-knowledge proof of knowledge (ZKPoK) based on requests from the `InputVerification` contract
-- handle access controls to ciphertexts for all registered [host chains](./gateway_config.md#host-chains), which are
-  centralized in the `MultichainAcl` contract
+- handle access controls to ciphertexts for all registered [host chains](./gateway_config.md#host-chains), which are centralized in the `MultichainAcl` contract
 
 Several metadata are stored for each coprocessor:
 
 - `name` : name of the coprocessor (indicative)
 - `txSenderAddress` : see [Sender and signer](#sender-and-signer) below.
 - `signerAddress` : see [Sender and signer](#sender-and-signer) below.
-- `s3BucketUrl` : URL of the S3 bucket where the ciphertexts are stored. In the fhevm protocol, this URL is fetched by
-  the KMS connector in order to download the ciphertexts needed for decryption requests.
+- `s3BucketUrl` : URL of the S3 bucket where the ciphertexts are stored. In the fhevm protocol, this URL is fetched by the KMS connector in order to download the ciphertexts needed for decryption requests.
 
 The current list of [active](#lifecycle) coprocessors can be retrieved using the following view function:
 
@@ -38,34 +34,27 @@ A coprocessor has both a transaction sender and a signer assigned to it:
 - `txSenderAddress` : address of the account that will send transactions to the fhevm Gateway.
 - `signerAddress` : address associated to the public key used to sign results sent to the fhevm Gateway.
 
-The current list of [active](#lifecycle) coprocessors' transaction senders and signers can be retrieved using the
-following view functions:
+The current list of [active](#lifecycle) coprocessors' transaction senders and signers can be retrieved using the following view functions:
 
 - `getCoprocessorTxSenders()`: get all the active coprocessors' transaction senders.
 - `getCoprocessorSigners()`: get all the active coprocessors' signers.
 
 The transaction sender and signer addresses are allowed to be the same for a given coprocessor.
 
-Additionally, the transaction sender address is used for identifying a coprocessor and may be referred to its
-"identity". In particular, these addresses can be used as inputs to following view function for [active](#lifecycle)
-coprocessors:
+Additionally, the transaction sender address is used for identifying a coprocessor and may be referred to its "identity". In particular, these addresses can be used as inputs to following view function for [active](#lifecycle) coprocessors:
 
 - `getCoprocessor(address coprocessorTxSenderAddress)`: get an active coprocessor's metadata.
 
 ## Coprocessor context
 
-A set of coprocessors is called a coprocessor context and must be constituted of at least 1 coprocessor. It stores the
-following metadata:
+A set of coprocessors is called a coprocessor context and must be constituted of at least 1 coprocessor. It stores the following metadata:
 
-- `contextId`: unique non-zero identifier of the coprocessor context, defined using an incremental counter within the
-  `CoprocessorContexts` contract.
+- `contextId`: unique non-zero identifier of the coprocessor context, defined using an incremental counter within the `CoprocessorContexts` contract.
 - `previousContextId`: identifier of the previous coprocessor context.
 - `featureSet`: feature set of the coprocessor context, used for updating the coprocessors' software.
 - `coprocessors`: list of coprocessors in the coprocessor context.
 
-Currently, the initial coprocessor context is set at deployment of the `CoprocessorContexts` contract and put directly
-in the [`active`](#lifecycle) state. In this particular case, the `previousContextId` is set to 0 since there is no
-previous coprocessor context to refer to.
+Currently, the initial coprocessor context is set at deployment of the `CoprocessorContexts` contract and put directly in the [`active`](#lifecycle) state. In this particular case, the `previousContextId` is set to 0 since there is no previous coprocessor context to refer to.
 
 Coprocessor contexts can be updated over time by the owner for the following reasons:
 
@@ -76,21 +65,17 @@ Coprocessor contexts can be updated over time by the owner for the following rea
 
 ### Lifecycle
 
-Coprocessor context updates follow a lifecycle approach, a general concept applied to other parts of the fhevm Gateway
-(ex: KMS nodes, Custodians, FHE keys). It is used to ensure a linear history of contexts and that there is no disruption
-in the protocol when updating them.
+Coprocessor context updates follow a lifecycle approach, a general concept applied to other parts of the fhevm Gateway (ex: KMS nodes, Custodians, FHE keys). It is used to ensure a linear history of contexts and that there is no disruption in the protocol when updating them.
 
-The lifecycle of a context is defined by the following states, although some of them are not currently used in practice
-for coprocessor contexts:
+The lifecycle of a context is defined by the following states, although some of them are not currently used in practice for coprocessor contexts:
 
 - `generating`: currently not used.
 - `pre-activation`: the coprocessor context will be activated in a certain amount of blocks.
 - `active`: the coprocessor context can be used for new requests, for example:
   - input verification requests
   - adding new ciphertext materials
   - new allows or delegations
-- `suspended`: the coprocessor context cannot be used for new requests and will be deactivated after a certain amount of
-  blocks. However, it can still be considered for on-going consensus phases, for example:
+- `suspended`: the coprocessor context cannot be used for new requests and will be deactivated after a certain amount of blocks. However, it can still be considered for on-going consensus phases, for example:
   - proof verification/rejection responses
   - on-going additions of ciphertext materials
   - on-going allows or delegations
@@ -100,20 +85,16 @@ for coprocessor contexts:
 
 Additionally:
 
-- in case of emergency (ex: bad software update), the owner can directly move a context from `suspended` back to
-  `active`, which deactivates the context with issues.
-- an `active` context cannot be set to `compromised`,`deactivated` or `destroyed`, in order to ensure that the fhevm
-  Gateway always has one active context.
+- in case of emergency (ex: bad software update), the owner can directly move a context from `suspended` back to `active`, which deactivates the context with issues.
+- an `active` context cannot be set to `compromised`,`deactivated` or `destroyed`, in order to ensure that the fhevm Gateway always has one active context.
 
 The complete lifecycle of a coprocessor context is represented in the following diagram:
 
 ![Context lifecycle](../../.assets/lifecycle_contexts.png)
 
 ### Automatic status refresh
 
-Coprocessor context statuses that need to be updated based on the current block number are refreshed using the
-`refreshCoprocessorContextStatuses` function. This function can be called by anyone, but most importantly, it is called
-by any of the following functions as a pre-hook modifier:
+Coprocessor context statuses that need to be updated based on the current block number are refreshed using the `refreshCoprocessorContextStatuses` function. This function can be called by anyone, but most importantly, it is called by any of the following functions as a pre-hook modifier:
 
 - in `CiphertextCommits` contract:
   - `addCiphertextMaterial`
@@ -130,8 +111,7 @@ This ensures that the statuses are always up to date when performing the above a
 
 ## Owner
 
-Similarly to other contracts, the `CoprocessorContexts` contract is ownable. The `owner` account is allowed to perform
-several restricted actions:
+Similarly to other contracts, the `CoprocessorContexts` contract is ownable. The `owner` account is allowed to perform several restricted actions:
 
 - upgrade the contract
 - add a new coprocessor context

gateway-contracts/docs/getting-started/deployment/env_variables.md

@@ -151,9 +151,7 @@ HOST_CHAIN_WEBSITE_0="https://host-chain-2025.com" # (string)
 
 ### CoprocessorContexts values
 
-These values are crucial for the fhevm Gateway protocol and are set in the `CoprocessorContexts` contract at deployment.
-To understand what each value is used for, please refer to the
-[CoprocessorContexts](../contracts/coprocessor_contexts.md) documentation.
+These values are crucial for the fhevm Gateway protocol and are set in the `CoprocessorContexts` contract at deployment. To understand what each value is used for, please refer to the [CoprocessorContexts](../contracts/coprocessor_contexts.md) documentation.
 
 #### At deployment
 
@@ -173,10 +171,7 @@ This integer is used to identify the feature set of the coprocessors for softwar
 NUM_COPROCESSORS="3" # (number)
 ```
 
-`NUM_COPROCESSORS` is the number of coprocessors to register in the `CoprocessorContexts` contract. It it not stored in
-it and is only used within the deployment script. The following metadata variables must be set for each coprocessor,
-indexed by a coprocessor number starting from 0. If not enough variables are set, the deployment will fail. If, on the
-contrary, too many variables are set, the deployment will succeed but the extra ones will be ignored.
+`NUM_COPROCESSORS` is the number of coprocessors to register in the `CoprocessorContexts` contract. It it not stored in it and is only used within the deployment script. The following metadata variables must be set for each coprocessor, indexed by a coprocessor number starting from 0. If not enough variables are set, the deployment will fail. If, on the contrary, too many variables are set, the deployment will succeed but the extra ones will be ignored.
 
 ```bash
 COPROCESSOR_NAME_0="Coprocessor 1" # (string)