Resource Model
Introduction
Vision Network has four types of resources: Photon, CPU, Storage and RAM. Benefit by Vision's exclusive RAM model, Vision's RAM resource is almost infinite.
Vision Network imports two resource conceptions: Photon points and Entropy. Photon Point represents Photon; Entropy represents CPU and Storage.
Vision Network also introduced two quantifiable resources, FV and SPREAD, where FVGUARANTEE means node pledge, and SPREAD means promotion pledge.
Note:
Ordinary transaction only consumes Photon points
Smart contract related transaction consumes not only Photon points, but also Entropy
Photon Points
The transaction information is stored and transmitted in the form of the byte array; Photon Points consumed = the number of bytes of the transaction * Photon Points rate. Currently Photon Points rate = 1
Such as if the number of bytes of a transaction is 200, so this transaction consumes 200 Photon Points.
Note: Due to the change of the total amount of the frozen VS in the network and the self-frozen VS amount, the Photon Points an account possesses is not fixed.
1. How to Get Photon Points
By Freezing VS to get Photon Points, Photon Points = the amount of VS self-frozen / the total amount of VS frozen for Photon Points in the network * 2_000_000_000
Every account has a fixed amount of free Photon Points(5000) every day
2.Photon Points Consumption
Except for query operation, any transaction consumes Photon points.
There's another situation: When you transfer(VS or token) to an account that does not exist in Vision Network, this operation will first create that account in the network and then do the transfer. It only consumes Photon points for account creation, and no extra Photon points consumption for transfer.
Create a new account transaction, BaPhoton dwidth points consumption sequence: 1.Photon points from freezing VS. If transaction initiator does not have enough Photon Points of this type, it will go to step 2;
Burn 0.1 VS; Token transfer transaction, Photon points consumption sequence:
Firstly, check if the total free Photon Points of the token issuer is enough. Then, check if the transfer Initiator‘s remaining token free Photon Points is enough. Finally check if the Photon Points of token issuer obtained by freezing VS is enough. Otherwise, it will go to step 2;
Photon points from freezing VS. If transaction initiator does not have enough Photon Points of this type, it will go to step 3;
Free Photon points. If transaction initiator does not have enough Photon Points of this type, it will go to step 4;
Photon points from burning VS, the rate = the number of bytes of the transaction * 10 VDT; The ordinary transaction, Photon points consumption sequence:
Photon points from freezing VS. If transaction initiator does not have enough Photon Points of this type, it will go to step 2;
Free Photon points. If transaction initiator does not have enough Photon Points of this type, it will go to step 3;
Photon points from burning VS, the rate = the number of bytes of the transaction * 10 VDT;
3. Photon Points Recovery
Every 24 hours, the amount of the usage of Photon points of an account will be reset to 0. For the specific formula:
Every 24 hours, the amount of the usage of Photon points of an account will be reset to 0.
Entropy
When a smart contract is running, each instruction needs to consume a certain amount of system resources, and the amount of resources is measured by the value of entropy.
1. Acquisition of entropy
Freeze the acquisition of entropy, which means that the VS that is about to be held will be locked and cannot be traded as collateral, so as to obtain the right to use entropy for free. The specific calculation is related to the freezing of all accounts on the entire network, and you can refer to the relevant part of the calculation.
FreezeBalance freezes to get entropy
Entropy obtained by freezing VS, quota = VS frozen for obtaining Entropy / total network frozen VS for obtaining Entropy * 3_000_000_000. That is, all users divide Entropy with a fixed amount according to freezing VS. Example: For example, there are only two people in the entire network, A and B, freeze 2VS and 2VS respectively. The available Entropy obtained by freezing is A: 1_500_000_000 and entropy_limit is 1_500_000_000 B: 1_500_000_000 and entropy_limit is 1_500_000_000
When the third person C freezes 1VS. The available entropy obtained by freezing three people is adjusted to A: 1_200_000_000 and entropy_limit is adjusted to 1_200_000_000 B: 1_200_000_000 and entropy_limit is adjusted to 1_200_000_000 C: 600_000_000 and entropy_limit is 600_000_000 FreezeBalance restore entropy The entropy consumed will smoothly decrease to 0 within 24 hours. Example: At a certain moment, A's entropy has been used at 72_000_000 entropy, and there is no other consumption or freezing operation:
One hour later, A's entropy used amount is 72_000_000-(72_000_000 (6060/606024)) entropy = 69_000_000 entropy
After 24 hours, A's entropy has been used to 0 entropy.
2. How to fill in feeLimit (user must read)
Within the scope of this section, the contract developer is referred to as the "developer"; the user or other contract that invokes the contract is referred to as the "caller".
The entropy consumed by the invoking contract can be converted into VS (or vdt) in a certain proportion. Therefore, within the scope of this section, when referring to the resources consumed by the contract, entropy and VS are not strictly distinguished; they are only distinguished when they are used as the unit of value. entropy, VS and vdt.
Reasonable setting of feeLimit, on the one hand, can ensure normal execution as much as possible; on the other hand, if the entropy required by the contract is too large, it will not consume too much VS of the caller. Before setting feeLimit, you need to understand several concepts:
1). The legal feeLimit is an integer value between 0-10^9, the unit is vdt, which is equivalent to 0-1000 VS;
2). Contracts of different complexity consume different entropy for each normal execution; the entropy consumed by the same contract is basically the same every time; when the contract is executed, the entropy is calculated and deducted instruction by instruction. If the limit of feeLimit is exceeded, the contract execution fails. The deducted entropy is not refundable;
3). At present feeLimit only refers to the entropy equivalent of the VS that the caller is willing to undertake; the maximum entropy allowed by the execution contract also includes the part borne by the developer;
4). For a malicious contract, if the final execution times out or the contract crashes due to a bug, all entropy allowed by the contract will be deducted;
5). Developers may bear a certain percentage of entropy consumption (for example, 90%). However, when the entropy of the developer account is not enough to pay, the remaining part is completely borne by the caller. Within the limit of feeLimit, if the caller's entropy is insufficient, the equivalent value of VS will be burned.
Developers usually have sufficient entropy to encourage low-cost calls; when estimating feeLimit, the caller can assume that the developer can assume the entropy of his commitment ratio. If a call fails due to insufficient feeLimit, it can be expanded appropriately.
3. Entropy calculation (developer must read)
Before discussing this chapter, you need to know: 1). Vision In order to punish malicious developers, for abnormal contracts, if the execution times out (more than 50ms) or exits due to a bug (not including revert), the maximum available entropy will be deducted this time. If the contract is executed normally or reverted, only the entropy required to execute the relevant instruction will be deducted;
2). Developers can set the percentage of entropy to be consumed when executing the contract, and the percentage can be modified later. The entropy consumed by a contract call, if the developer’s entropy is not enough to pay for the part it undertakes, the caller will pay for the remaining part;
3). Currently executing a contract, the total number of entropy available is determined jointly by the feeLimit set by the caller and the developer's responsibility;
Notice:
If the developer is not sure whether the contract is normal, please do not set the user's commitment ratio to 0%, otherwise all entropy of the developer will be deducted when it is judged to be executed maliciously.
Therefore, it is recommended that the developer set the user's share of 10% to 100%.
If the contract is executed successfully without any exception, the entropy actually consumed by the contract operation will be deducted, which is generally much smaller than the entropy that can be used in this call. If an Assert-style exception occurs, all entropy corresponding to feeLimit will be consumed.
Notice: When the developer creates a contract, consume_user_resource_percent should not be set to 0, that is, the developer is responsible for all resource consumption. The developer is responsible for all resource consumption, which means that when an Assert-style exception occurs, all entropy frozen by the developer will be consumed.
FVPledge
The number of votes obtained by the first validator will be weighted by the fv pledge. The threshold is 5000VS. The calculation formula for the weight of the votes: (weight of votes-5000VS) * 6.5% >= actual count of votes
The specific operation of the Vision node pledge is executed in the wallet as above, the freezing type ResourceCode is set to 2, and the receiverAddress is not required to fill in.
Resource Delegation
In Vision network, an account can freeze VS for Photon or Entropy for other accounts. The primary account owns the frozen VS and Vision power, the recipient account owns the Photon or Entropy. Like ordinary freezing, resource delegation freezing is also at least 3 days.
Last updated
