added information about testnet

src/cloud/cli.md

@@ -37,7 +37,7 @@ Account Balance: 980.16022 DeTEE Tokens available, 0 Tokens locked
 SNP admin secret key path: /home/ghe0/.detee/cli/secret_detee_wallet_key
 ```
 
-And give it to us on Discord so that we can give you your airdrop (assuming you have [access](./access.md)).
+And give it to us on Discord so that we can give you your airdrop (assuming you have follow [the tutorial](./access.md)).
 
 ### Deploy a VM
 

src/cloud/components.md

@@ -6,7 +6,7 @@ DeTEE is built of multiple components that are already under development, as fol
   - [x] allows you to create contracts for VMs and containers
   - [ ] allows you to create contracts for GPUs
   - [ ] allows users to vote for the upgrades of the platform
-  - [x] stores ratings for users
+  - [x] stores ratings for users and servers
   - [ ] allows you to deposit and withdraw DeTEE tokens via different blockchains
 
 - **(Intel) SGX Daemon**: Software that powers the SGX node, allowing customers to run containers

src/cloud/join_as_user.md

@@ -3,11 +3,12 @@
 Please be aware this product has been designed for:
 - DevOps engineers
 - Cloud engineers
+- Web3 engineers
 - Software developers
 - Cybersecurity enthusiasts
 
 Having basic understanding of operating systems, containers, virtual machines and deployment of software is required in order to use the CLI. The product was heavily inspired from existing open source cloud apps (Docker, Kubernetes, Proxmox, OpenStack).
 
-As we are currently in a testnet phase, you will first have to get some tokens in order to be able to test the app. Details on how to get access can be found in the next chapter.
+As we are currently entering the testnet phase, you will first have to get some tokens in order to be able to test the app. Details on how to get access can be found in the next chapter.
 
 <script type="text/javascript" id="hcb" src="/js/comments.js"></script><div id="HCB_comment_box"></div><link rel="stylesheet" type="text/css" href="/css/comments.css"/>

src/cloud/tokens.md

@@ -11,17 +11,17 @@ The token payment and reward mechanism of DeTEE is based on the core concepts of
 - the guest can not access the host
 - the host can not access the guest
 
-One of the first conclusions after analyzing the requirements above is that designing a mechanism was that implementing payment for resource utilization is exceptionally hard. As a consequence, DeTEE currently supports only payment for resource reservation, and different models will be considered as the project grows. This means that the user will pay for the resources he reserves, not for the resources he uses. For example, if a user reserves a VM with 4 vCPUs and 5GB of memory, however the load on the VM is minimal, the user will still pay for vCPUs and 5 GBs of memory. To compensate for this, automation and orchestration tools will be offered to users.
+One of the first conclusions after analyzing the requirements above is that designing a mechanism was that implementing payment for resource utilization is exceptionally hard. As a consequence, DeTEE currently supports only payment for resource reservation, and different models will be considered as the project grows. This means that the user will pay for the resources he reserves, not for the resources he uses. For example, if a user reserves a VM with 4 vCPUs and 5GB of memory, however the load on the VM is minimal, the user will still pay for 4 vCPUs and 5 GBs of memory. To compensate for this, automation and orchestration tools will be offered to users.
 
-Though nodes get paid for resource reservation, during the testnet nodes will also receive a base reward of 100 test tokens per month. This means that all nodes will receive by default 100 test tokens per month in the testnet, no matter if they sell or not.
+Though nodes get paid for resource reservation, during the testnet nodes will also receive additional bonus tokens for participating. This means that all nodes will receive by a baseline of tokens per month in the testnet, no matter if they sell or not.
 
 ## Resource calculation
 
 Before calculating the price per month for a VM or a container, we must define the formula to calculate the multiplier for each hardware resource that is part of the contract. To simplify the formula, we will define “units”, each class of hardware warning units based on their own multiplier.
 
-Based on our experience when using cloud services, we decided that the price of a resource will be calculated based on the number of minutes the resource is being used. As a consequence, using a resource for 10 seconds will qualify as using that resource for 1 minute, and using the resource for 70 seconds will qualify as using the resource for 2 minutes.
+Based on our experience when using cloud services, we decided that the price of a resource will be calculated based on the number of minutes the resource is being used.
 
-A server is also free to choose the price per unit per minute for his service. This price is defined in nanotokens. The current recommended value is 20k nanotokens per unit per minute. With the current calculation, a VM with 1 vCPU, 1 GB of memory, 20 GB of storage and one public IP will cost 24.4 tokens per month.
+A server is also free to choose the price per unit per minute for his service. This price is defined in nanotokens (one nanotoken is 0.000000001 tokens). The current recommended value is 20k nanotokens per unit per minute. With the current calculation, a VM with 1 vCPU, 1 GB of memory, 20 GB of storage and one public IP will cost 24.4 tokens per month.
 
 ### Units
 
@@ -33,7 +33,7 @@ For now, the multipliers offered for hardware are:
 - 10 GB of Storage - offers 1 unit 
 - 1 public IPv4 IP - offers 10 units
 
-VMs also have an overhead for the memory due to SNP requirements.
+VMs also have an overhead of 256MB for the memory due to SNP requirements.
 
 As such, the calculation of the total units of a VM is:
 

src/operators/AMD.md

@@ -8,7 +8,7 @@ To be able to run the server on the network, it must support SEV SNP, meaning it
 - AMD EPYC 9004 (Genoa or Bergamo)
 - AMD EPYC 9005 (Turin)
 
-More information about the capabilities of each generation can be found on the [AMD website](https://www.amd.com/en/products/processors/server/epyc/infinity-guard.html). Our focus is strictly focused on the SEV-SNP capability.
+More information about the capabilities of each generation can be found on the [AMD website](https://www.amd.com/en/products/processors/server/epyc/infinity-guard.html). Our efforts are strictly focused on the SEV-SNP capability.
 
 The server must have a public IP.