Adjust tokenomics params to reflect difference in block time
Democracy
5 Comments
Tabled

Phala forum thread here

I would like to propose adjustment in tokenomics params to reduce impact of gap between real and target block time.

Target time on parachains is 12s.
Those are our avg block times calculated based on onchain data.

Average block time in last  1 day     16.4 s
Average block time in last  1 week    15.7 s
Average block time in last  2 weeks   15.5 s
Average block time in last  1 month   16.1 s
Average block time in last  2 month   15.7 s

As you can see we have long term 30% gap. It impacts all features which base on block number (not timestamp).
For example mining rewards are block based - which directly impact APR of owners and stakers. It is worth noting that in app.phala.network all values you see are also block based.
If you calculate your APR time based you will see it differs for 30%

Worth noting (mentioned by team):
This issue occurs because substrate has limited (obvious) throughput in processing blocks and simultaneously Phala extremely utilize onchain actions.

Compare Moonriver and Khala below (at most it is even 100x more transactions).
Btw. Moonriver is second most used chain ;)

As you can see lot of things happens on Khala and it is probably not possible to improve throughput in short term.

However this proposal is to reduce impact of that issue.
IMO block time in any contract calculations should not be fixed to target 12s value.
I think we should periodically adjust that value to reflect real block time.
Depending how much it will vary we should adjust it monthly based on last month average block time.

Edited
Reply
Up 2
Share
Second
No current seconds
This proposal has been turned into referendum.
Metadata
hash
0x3fb8adf8a43d49fefa480749bfba3a70c12ee707a2c0c7b171a842e5ee6d1b7d
deposit
10 PHA
proposer
TimelineLatest activity undefined
2021-12-07 06:41:18
Proposed
Index
#8
2021-12-24 23:40:12
Tabled
Referendum Index
#15
Deposit
10 PHA
Depositors
6
Comments

Very reasonable, especially given the block time is not achievable by the Kusama validator throughputs.

Reply
Up

I hereby confirm that the Proposal and the Proposal Hash is correct. I've reproduced the same encoded proposal and hash on my own.

  • Encoded Call: 0x5d03045705508d976e1283c0aa0000000000000000fd7eb4062f0b000001000000000000000000000000000070080000000000000000000000000000003075000000000000255a8ed66500000000000000000000009d3473f8f34f030000000000000000000000000000000000000000000000000033333333333333330000000000000000140000003b1c318036762473000000000000000000000000000000000000000000000000000000000000008001000000000000000000000000000000320000000000000000000000000000000100000000000000
  • NotePreimage extrinsic on Subscan: https://khala.subscan.io/extrinsic/851551-21
  • Proposal Hash (from the extrinsic event): 0x3fb8adf8a43d49fefa480749bfba3a70c12ee707a2c0c7b171a842e5ee6d1b7d
Edited
Reply
Up

Agree

Reply
Up

We have to resubmit the proposal due to the wrong preimage encoding! Please don't vote or second it!

The encoding of this proposal is incorrect. We need to submit the "raw encoded proposal" instead of the polkadot.js prefixed version. Please don't second this proposal!

Details here: https://forum.phala.network/t/topic/3274/12

这个提案的call编码有问题,需要重新提交,请不要为此提案投票!

虽然提案的内容是正确的,但作为公投提案,必须提交call的原始编码,而不是polkadot.js生成的带前缀的编码。请不要second这个提案!

详情原因请见: https://forum.phala.network/t/topic/3274/12

Reply
Up

The resubmission: Proposal #9

请参见新的提案 #9

Reply
Up