74 lines
4.8 KiB
Markdown
74 lines
4.8 KiB
Markdown
# Loyalty Points
|
|
|
|
> During the testnet phase, users of the DeTEE network will be able to run containers and VMs through the exchange of Loyalty Points (LP). Considering how young this project is, the calculations and rates of LP/resource will probably change. With time, this model will evolve into the DeTEE token, after the token gets released. This also means that [earning LP](access.md) during the testnet phase will get you airdrops after token release.
|
|
|
|
The LP payment and reward mechanism of DeTEE is based on the core concepts of the open market and the requirements of creating a TEE-based decentralized cloud platform:
|
|
- nodes are free to choose their price
|
|
- users are free to choose nodes based on their rating and price
|
|
- nodes are free to refuse contracts (or users)
|
|
- the cost of an enclave must be based on the amount of resources used
|
|
- enclaves can not be migrated (they are bound to the server)
|
|
- 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 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 additional bonus LP for participating. This means that all nodes will receive by a baseline of LP 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.
|
|
|
|
A server is also free to choose the price per unit per minute for his service. This price is defined in nanoLP (one nanoLP is 0.000000001 LP). The current recommended value is 20k nanoLP 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 LP per month.
|
|
|
|
### Units
|
|
|
|
> The current mechanism does not distinguish based on the quality of the hardware. In the future, you should expect to see tiers for disk and for memory.
|
|
|
|
For now, the multipliers offered for hardware are:
|
|
- 1 vCPU - offers 10 units
|
|
- 1 GB of Memory - offers 5 units
|
|
- 10 GB of Storage - offers 1 unit
|
|
- 1 public IPv4 IP - offers 10 units
|
|
|
|
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:
|
|
|
|
```
|
|
total_units = (vcpus * 10) + ((memory_mb + 256) / 200) + (disk_gb / 10) + (public_ipv4 * 10)
|
|
```
|
|
|
|
## Price and time
|
|
|
|
> This page is exposiong a model that strictly applies to testnet LP that has no value. When the public token is launched, the token price will fluctuate independently, which will make any recommendation irrelevant to operators or users.
|
|
|
|
The node is free to choose the price for its services, expressed in nanoLP per unit. The recommended value is 20k. Please find below calculations for a price of 10k, 20k and 40k nanoLP per unit per minute.
|
|
|
|
For this example, let's take into consideration 3 types of VMs:
|
|
- a mini VM: 1 vCPUs, 1 GBs of memory and 10GBs of storage
|
|
- a medium VM: 5 vCPUs, 10 GBs of memory and 100GBs of storage
|
|
- a big VM: 16 vCPUs, 32 GBs of memory and 400GBs of storage
|
|
|
|
For the calculation, all VMs have a dedicated public IPv4 address.
|
|
|
|
In this table you can see the rounded price in LP per month for the these VM types:
|
|
|
|
| node price | mini VM | med vm | big VM |
|
|
| ------------------ | --------- | ---------- | --------- |
|
|
| 10k nanoLP/unit/min | ~12 T/mo | ~52 T/mo | ~160 T/mo |
|
|
| 20k nanoLP/unit/min | ~24 T/mo | ~105 T/mo | ~320 T/mo |
|
|
| 40k nanoLP/unit/min | ~47 T/mo | ~210 T/mo | ~641 T/mo |
|
|
|
|
Full calculation of price per month for one mini VM at a node price of 20k nanoLP:
|
|
```
|
|
((1 * 10) + (1256 / 200) + (10 / 10) + 10) * 20000 * 60 * 24 * 30 / 1_000_000_000 =
|
|
23.56992
|
|
```
|
|
|
|
As a result, a node selling 31 mini VMs for one month at a default price of 20k/unit/min will earn 730 LP.
|
|
|
|
<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"/>
|