HBD的供应量占比是如何计算出来的 & HF24时被我忽略掉的变化
最近HIVE上的小伙伴可能被文章奖励中的HBD发放情况给整懵了(话说你们明白这是啥意思不?),除了雷打不动的HP外,之前一段时间发放的全是HBD,然后又是HBD+HIVE,然后又是纯HIVE,现在又回到全是HBD的情况啦。
(图源 :pixabay)
其实这些都是系统自我调节的啦,把我之前文章中的部分内容拿来直接用:
HBD供应量控制在9%-10%之间,如果低于9%,那么文章奖励的流动性部分就100%发HBD(亦即HBD+HP),如果超过10%,那么就停发HBD(亦即HIVE+HP),9%-10%之间呢,则按线性比例发放。
最终这个供应量占比计算出来一个发放比例,也就是:HBD_PRINT_RATE,上节我们详细介绍过它,这里我们不过多介绍了,现在一个新问题是HBD的供应量占比是如何计算出来的?
其实单纯从字面意思,不看代码,我们也不难分析出来这个占比如何计算,无外乎HBD的资产比上系统的总资产。而系统的总资产其实有三个部分:
- 总的HP
- 总的HIVE
- 以及总的HBD
其中总的HP+HIVE,系统中使用current_supply来记录,总的HBD,系统中使用current_sbd_supply,要计算比例的话,需要先把HBD资产的价值换算成HIVE,这可以通过median_price来计算。
我们可以使用get_dynamic_global_properties来获取current_supply以及current_hbd_supply,可以用get_current_median_history_price来获取median_price,这样就可以计算出总资产了,也就不难计算出占比了。
而这个总资产,其实系统中是有一个参数一直记录了,同样可以通过get_dynamic_global_properties获取,它叫做:virtual_supply。
也就是说,我们可以通过计算的方式获得virtual_supply也可以直接获取virtual_supply,然后用折算成等值HIVE的总HBD资产去计算比值,就可以得出供应量占比啦。
比如我撰写本稿时,使用代码读取以及计算出上述数值:
median_price: 0.644
current_supply: 357643553.419
current_hbd_supply: 28404073.896
virtual_supply_read: 401749258.226
virtual_supply_cal: 401749258.2264534
对照上述数值以及命令行钱包读取出来的数值,完全一致,说明读取还是计算都没问题。
然而用上述数值计算出来的占比以及HBD_PRINT_RATE却与系统提供的数值大相径庭,问题出在哪里呢?查看database.cpp的内容,我发现如下函数:
从这个函数的名字database::calculate_HBD_percent不难看出它用来计算HBD占比的,然而和我的逻辑不同,这其中增加了红框部分代码。
也就是说HF24之后,计算HBD占比时,把国库(翻译成基金会更好一些?)中HBD减除掉了。而在HIVE中,国库账户为:
#define NEW_HIVE_TREASURY_ACCOUNT "hive.fund"
所以我的代码中也要按这个逻辑处理才行,我直接使用get_accounts读取 "hive.fund"这个账户中的HBD余额(hbd_balance),并将其从current_sbd_supply减除掉。
然后用更新后的current_sbd_supply以及current_supply以及median_price来计算virtual_supply并计算占比。
这次得到的结果就正常啦:
而阅读一下HIVE v1.24.2(HF24)的Release log中会发现这样一条内容:
The HBD in the decentralized hive fund doesn't count towards the debt ratio
(图源 :pixabay)
而v1.24.2的发布日期是2020年10月份,也就是说足足过了一整年我才发觉这个变化,惭愧呀!
相关链接
Leave HBD的供应量占比是如何计算出来的 & HF24时被我忽略掉的变化 to:
Read more #cn posts
Best Posts From oflyhigh
We have not curated any of oflyhigh's posts yet. But you can encourage our curation team to review posts by visiting them regularly and by referring other readers. Because we give priority to frequently read content.