readme update

README.md

@@ -11,24 +11,26 @@ A Web3-Powered (Near), Decentralized Quantum Simulator with Verifiable Computati
 
 The DQPU system is composed of 3 actors:
 
-- *Clients*: users who need to perform a quantum sampling in exchange of a reward
-- *Verifiers*: delegated who check for data validity and detect cheating users; it receives a reward for its validation job.
+- *Clients*: users who need to perform a quantum sampling paying a reward
+- *Verifiers*: delegates who check for data validity and detect cheating users; they receive a reward for checking quantum sampling result validity
 - *Samplers*: users who run quantum samplers (either simulator or real quantum computers) and receive
 a reward for doing sampling
 
 The following process outlines how clients can submit quantum circuits for sampling using the DQPU contract:
 
 1. **Client Submits Job**: A *Client* sends a quantum circuit along with a reward to the DQPU smart contract. The circuit data is uploaded to a distributed file storage system like IPFS. The smart contract adds the job to a queue in a 'pending' state with the associated reward.
 
-2. **Verifier Validates Circuit**: A *Verifier* designated by the smart contract validates the submitted circuit. This might involve checks for syntax errors or ensuring the circuit is within allowed parameters. The verifier also adds special verification elements (traps) into the circuit. Once validated, the job moves to a 'waiting' state.
+2. **Verifier Validates Circuit**: A *Verifier*[^1] validates the submitted circuit. This might involve checks for syntax errors or ensuring the circuit is within allowed parameters. The verifier also adds special verification elements (traps) into the circuit. Once validated, the job moves to a 'waiting' state.
 
 3. **Simulation or Hardware Execution**: A *Sampler* retrieves a job from the waiting list. It then either simulates the circuit on a software program or executes it on real quantum hardware, depending on the job requirements and available resources. The simulation or execution result is submitted back to the smart contract with a cautional deposit (a percentage of the reward). The job status changes to 'validating'.
 
-4. **Verifier Checks Result**: The same *Verifier* from step 2 examines the returned result. The *Verifier* specifically checks the traps inserted earlier to ensure the result hasn't been tampered with. If the trap verification succeeds, the job status is updated to 'executed' and the *Sampler* account receives the reward.
+4. **Verifier Checks Result**: The same *Verifier* from step 2 examines the returned result. The *Verifier* specifically checks the traps inserted earlier to ensure the result hasn't been tampered with. If the trap verification succeeds, the job status is updated to 'executed' and the *Sampler* account receives the reward, while the *Verifier* receives a percentage of this reward.
 If the trap verification fails, the job returns in 'waiting' state (and the *Verifier* receives the cautional deposit of the *Sampler*).
 
 5. **Client Receives Result**: Once the job is marked as 'executed', the *Client* can retrieve the final result from the smart contract.
 
+[^1]: In this first version of the contract, *Verifiers* are trusted entities designated by the smart contract creator.
+
 
 ## Installation