English

资源模型

Suggest Edits

资源模型介绍

Vision Network中的资源：光量子，熵 以及 社区节点投票， 节点保证金。
Vision Network 引入了PhotonPoint 和 Entropy 两种可以进行量化的资源。其中Photon Point表示光量子资源，Entropy 表示熵资源。

Vision Network同时引入了FVGUARANTEE（节点质押保证金）和CommunityVoting（社区节点投票） 两种可以量化的Staking资源，其中FVGUARANTEE表示节点质押，CommunityVoting表示社区节点投票质押

注意:

  • 执行系统交易仅消耗PhotonPoint
  • 执行智能合约的操作不仅要消耗PhotonPoint ，同时还会消耗Entropy

光量子

交易以字节数组的形式在网络中传输及存储，一条交易消耗的PhotonPoints = 交易字节数 * PhotonPointsPoint费率。当前Photon Point费率 = 1。

如一条交易的字节数组长度为200，那么该交易需要消耗200 PhotonPoints。

注意: 由于网络中总冻结资金以及账户的冻结资金随时可能发生变化，因此账户拥有的PhotonPoints不是固定值。

1. PhotonPoints的来源

PhotonPoints的获取分两种：

通过冻结VS获取的PhotonPoint， 额度 = 为获取PhotonPoint冻结的VS / 整个网络为获取PhotonPoints冻结的VS 总额 * 1_000_000_000。 也就是所有用户按冻结VS平分固定额度的Photon Points。
每个账号每天有固定免费额度的光量子，为5000。

2. Photon Points的消耗

除了查询操作，任何交易都需要消耗Photon Points。

还有一种情况，如果是转账，包括普通转账或者VRC10 Token转账，如果目标账户不存在，转账操作会先创建该目标账户然后再进行转账，并且这个过程中只会扣除创建账户消耗的Photon Points，之后的转账不会再消耗额外的Photon Points。

3. Photon Points的计算规则

Photon Points是一个账户1天内能够使用的总字节数。一定时间内，整个网络能够处理的Photon 为确定值。

如果交易需要创建新账户，Photon Points消耗如下：
1.尝试消耗交易发起者冻结获取的Photon Points。如果交易发起者Photon Points不足，则进入下一步
2.尝试消耗交易发起者的VS，这部分烧掉 0.1VS，记录为 Photon 消耗

如果交易是VRC10 token的转账，Photon Points消耗如下：
1.依次验证 发行Token资产总的免费Photon Points是否足够消耗，转账发起者的Token剩余免费Photon Points是否足够消耗，Token发行者冻结VS获取Photon Points剩余量是否足够消耗。如果满足则扣除Token发行者的Photon Points，任意一个不满足则进入下一步
2.尝试消耗交易发起者冻结获取的Photon Points。如果交易发起者Photon Points不足，则进入下一步
3.尝试消耗交易发起者的免费Photon Points。如果免费Photon Points也不足，则进入下一步
4.尝试消耗交易发起者的VS，交易的字节数 * 10 vdt

如果交易普通交易，Photon Points消耗如下：
1.尝试消耗交易发起者冻结获取的Photon Points。如果交易发起者Photon Points不足，则进入下一步
2.尝试消耗交易发起者的免费Photon Points。如果免费Photon Points也不足，则进入下一步
3.尝试消耗交易发起者的VS，交易的字节数 * 10 vdtS

4. 光量子的自动恢复

在网络总锁定资金以及账户锁定资金不变的情况下，账户的光量子的已使用量随着时间增加而按比例衰减，24h衰减到0。如时间T1时刻，账户光量子已使用量为U，到T1+12h，账户再次使用光量子u,此时账户已使用光量子为 U/2 + u。具体公式如下：

546

光量子恢复公式

即可以理解为每24h，用户已使用的光量子值重置为0。

熵

智能合约运行时执行每一条指令都需要消耗一定的系统资源，资源的多少用entropy的值来衡量。

1. entropy的获取

冻结获取entropy，即将持有的VS锁定，无法进行交易，作为抵押，并以此获得免费使用entropy的权利。具体计算与全网所有账户冻结有关，可参考相关部分计算。

FreezeBalance 冻结获得熵 

freezeBalance frozen_balance frozen_duration [ResourceCode:0 PHOTON,1 ENTROPY, 2 FIRST VALIDATOR, 3 CommunityVoting]

通过冻结VS获取的Entropy， 额度 = 为获取Entropy冻结的VS / 整个网络为获取Entropy冻结的VS 总额 * 2_000_000_000。
也就是所有用户按冻结VS平分固定额度的Entropy。
示例：
如全网只有两个人A，B分别冻结2VS，2VS。
二人冻结获得的可用Entropy分别是
A: 1_000_000_000 且entropy_limit 为1_000_000_000
B: 1_000_000_000 且entropy_limit 为1_000_000_000

当第三人C冻结1VS时。
三人冻结获得的可用entropy调整为
A: 800_000_000 且entropy_limit调整为800_000_000
B: 800_000_000 且entropy_limit调整为800_000_000
C: 400_000_000 且entropy_limit 为400_000_000
FreezeBalance 恢复熵
所消耗的熵会在24小时内平滑减少至0。
示例：
在某一时刻A的entropy已使用量为72_000_000 entropy，在没有其他消耗或冻结的操作下：

  • 一小时后A的entropy已使用量为 72_000_000 - (72_000_000 (6060/606024)) entropy = 69_000_000 entropy
  • 24小时后A的entropy已使用量为 0 entropy。

2. 如何填写feeLimit(用户必读)

在本节范围内，将合约的开发部署人员，简称为“开发者”；将调用合约的用户或者其他合约，简称为“调用者”。

调用合约消耗的entropy能以一定比例折合成VS（或者vdt），所以在本节范围内，指代合约消耗的资源时，并不严格区分entropy和 VS；仅在作为 数值的单位时，才区分entropy、VS和vdt。

合理设置feeLimit，一方面能尽量保证正常执行；另外一方面，如果合约所需entropy过大，又不会过多消耗调用者的VS。在设置feeLimit之前，需要了解几个概念：

1). 合法的feeLimit为0 - 10^9 之间的整数值，单位是vdt，折合0 - 1000 VS；

2). 不同复杂度的合约，每次正常执行消耗不同的entropy；相同合约每次消耗的entropy基本相同；执行合约时，逐条指令计算并扣除entropy，如果超过feeLimit的限制，则合约执行失败，已扣除的entropy不退还；

3). 目前feeLimit仅指调用者愿意承担的entropy折合的VS；执行合约允许的最大entropy还包括开发者承担的部分；

4). 一个恶意合约，如果最终执行超时，或者因bug合约崩溃，则会扣除该合约允许的所有entropy；

5). 开发者可能会承担一定比例的entropy消耗（比如承担90%）。但是，当开发者账户的entropy不足以支付时，剩余部分完全由调用者承担。在feeLimit限制范围内，如调用者的entropy不足，则会燃烧等价值的VS。

开发者通常会有充足的entropy，以鼓励低成本调用；调用者在估算feeLimit时，可以假设开发者能够承担其承诺比例的entropy，如果一次调用因为feeLimit不足而失败，可以再适当扩大。

3. entropy的计算(开发者必读)

在讨论本章节前，需要了解：

1). 为了惩罚恶意开发者，对于异常合约，如果执行超时（超过50ms），或因bug异常退出（不包含revert），Vision会扣除本次的最大可用entropy。若合约正常执行，或revert，则仅扣除执行相关指令所需的entropy；

2). 开发者可以设置执行合约时，消耗entropy中自己承担的比例，该比例后续可修改。一次合约调用消耗的entropy，若开发者的entropy不足以支付其承担的部分，剩余部分全由调用者支付；

3). 目前执行一个合约，可用的entropy总数由 调用者调用时设置的feeLimit 和 开发者承担部分共同决定；

注意：
1.若开发者不确定合约是否正常，请勿将用户承担比例设置为0%，否则在被判为恶意执行时，会扣除开发者的所有entropy。
2.因此建议开发者设置的用户承担的比例为10%~100%。

如果合约执行成功，没有发生任何异常，则会扣除合约运行实际消耗的entropy，一般都远远小于此次调用能够使用的entropy。如果发生了Assert-style异常，则会消耗feeLimit对应的所有的entropy。

注意：
开发者创建合约的时候，consume_user_resource_percent不要设置成0，也就是开发者自己承担所有资源消耗。
开发者自己承担所有资源消耗，意味着当发生了Assert-style异常时，会消耗开发者冻结的所有entropy。

节点质押

第一验证者获得票数会通过节点质押来加权重，门槛是2000VS，得票权重计算公式：（节点质押量 - 2000VS）* 6.5%

社区节点投票

Vision 引入社区节点投票机制，每个用户既可以作为节点，接收其他用户的投票，也可以作为选民，投票给其他社区节点。用户质押VS获得CommunityVoting奖励，质押时须填写社区节点地址，区别于fv节点投票，社区节点投票是只允许给一个节点投票，且一次投票后需等到解冻期3天后，才允许修改节点，追加质押不限制时间。

资源委托

在Vision中，一个账户可以通过冻结VS来获取光量子和熵。同时，也可以把冻结VS获取的光量子或者熵委托（delegate）给其他地址。
此时，主账号拥有冻结的VS以及相应的投票权，受委托账户拥有冻结获取的资源（光量子或者熵）。
和普通冻结一样，委托资源也至少冻结35天。

资源委托的命令如下：

freezeBalance frozen_balance frozen_duration [ResourceCode:0 PHOTON,1 ENTROPY, 2 FVGUARANTEE, 3 CommunityVoting] [receiverAddress]

frozen_balance是冻结的VS数量（单位为vdt）， frozen_duration为冻结的天数（目前固定为35天）， ResourceCode表示要获取的资源是光量子还是熵， receiverAddress表示受委托账户的地址.

Updated over 1 year ago